PolarDB 一写多读架构下读取到未来页的问题
原文中文，约2300字，阅读约需6分钟。
📝
内容提要
PolarDB/Aurora的共享存储架构中，RO节点的延迟会影响RW节点的刷脏操作。目前的解决方法是让RO节点自动重启，但有用户希望RO节点不重启。解决方案可以从RW节点或RO节点入手，但都存在一些问题。限制RW节点会导致内存不足和性能下降，持久化redo log会增加延迟。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无法推进。
🏷️
