PolarDB 物理复制SMO 同步机制
原文中文，约9500字，阅读约需23分钟。
📝
内容提要
该文章讨论了在mtr中修改多个页面时可能出现的搜索操作错误的问题。通过引入sync_counter机制，可以避免错误，但会导致物理复制效率下降。作者提出了使用smo page queue或LogIndex SMO page queue的方法来解决这个问题，并减少store和restore操作。此外，还讨论了使用LogIndex和bw-tree的方法来解决非smo场景下的冲突问题。最后，作者提出了一些问题和可能的解决方案。
❓
Q&A
sync_counter机制的主要作用是什么？
sync_counter机制主要用于解决在mtr中修改多个页面时可能出现的搜索操作错误问题。
引入sync_counter机制后有什么缺点？
引入sync_counter机制后，物理复制效率下降，并且可能导致频繁的store和restore操作，影响性能。
如何使用SMO page queue来解决问题？
SMO page queue通过传递SMO page ID到RO节点，减少不必要的store和restore操作，从而提高性能。
LogIndex方法是如何工作的？
LogIndex方法通过带上lsn信息来访问指定版本的Page，避免访问到不存在的Page。
bw-tree和LogIndex有什么区别？
bw-tree在内存中保存的是最老版本的Page，而LogIndex则保留最新版本的Page，磁盘中保存最老版本。
在非SMO场景下如何解决冲突问题？
可以使用LogIndex和bw-tree的方法来解决非SMO场景下的冲突问题。
🏷️
