PolarDB 一写多读架构下读取到未来页的问题
内容提要
PolarDB/Aurora的共享存储架构中，RO节点的延迟会影响RW节点的刷脏操作。目前的解决方法是让RO节点自动重启，但有用户希望RO节点不重启。解决方案可以从RW节点或RO节点入手，但都存在一些问题。限制RW节点会导致内存不足和性能下降，持久化redo log会增加延迟。RO节点处理不一致问题的方法简单但性能受影响。需要更细致的处理方法来解决逻辑和物理不一致问题。
延伸解读
RO延迟为何会拖累RW节点
在PolarDB/Aurora的共享存储架构中，RO节点的复制延迟会直接约束RW节点的刷脏操作。因为存储节点必须保留最老版本的数据页，以确保所有RO节点都能读取到一致版本。如果RO节点延迟过高，RW节点就无法推进刷脏，最终可能导致RW节点内存不足甚至崩溃。这与传统MySQL主备架构中备库不影响主库的认知完全不同。
自动重启并非唯一解，但替代方案各有代价
目前PolarDB和Aurora都采用RO节点自动重启来避免RW节点受影响，但用户希望RO节点不重启。若从RW节点入手限制刷脏，可能面临内存不足和性能下降；持久化redo log虽能规避内存问题，却会增加额外IO延迟。若从RO节点入手允许读取future page，则需处理逻辑不一致和物理不一致，简单重试会影响性能，更细致的方案尚待探索。
Aurora与PolarDB的架构差异影响风险程度
虽然两者都面临RO延迟导致的刷脏约束问题，但Aurora将延迟的page分散到多个Page Server上，而PolarDB则集中在单个节点。因此，当出现慢RO节点时，Aurora受到的影响相对较小，PolarDB的刷脏约束可能更集中地导致节点崩溃。这一差异意味着在PolarDB中，RO节点的延迟问题可能更为突出，需要更谨慎地处理。
Q&A
PolarDB的RO节点延迟会对RW节点造成什么影响？
RO节点的延迟会影响RW节点的刷脏操作，导致RW节点无法进行刷脏。
目前PolarDB如何处理RO节点的延迟问题？
目前的处理方法是让RO节点自动重启，以避免RW节点出现问题。
如果不限制RW节点刷脏，会出现什么问题？
如果不限制RW节点刷脏，RO节点可能会读取到future page，导致数据不一致。
PolarDB和Aurora在处理RO节点延迟方面有什么不同？
Aurora通过将延迟的page分散到多个Page Server上来减轻影响，而PolarDB则集中在一个节点上。
处理RO节点读取到future page的问题需要什么样的逻辑？
需要更复杂的逻辑来处理RO节点读取到future page的问题，包括逻辑不一致和物理不一致的判断。
PolarDB和Aurora在刷脏约束方面面临哪些风险？
两者都面临RO节点延迟过大导致的节点崩溃风险，PolarDB可能导致RW节点无法刷脏，Aurora则可能导致Page server无法推进。
