PolarDB Physical Replication SMO Synchronization Mechanism
💡
原文英文，约1200词，阅读约需5分钟。
📝
内容提要
该文章讨论了在mtr中修改多个页面时可能出现的搜索操作错误的问题。通过引入sync_counter机制，可以避免错误，但会导致物理复制效率下降。作者提出了使用smo page queue或LogIndex SMO page queue的方法来解决这个问题，并减少store和restore操作。此外，还讨论了使用LogIndex和bw-tree的方法来解决非smo场景下的冲突问题。最后，作者提出了一些问题和可能的解决方案。
🎯
关键要点
- 文章讨论了在mtr中修改多个页面时可能出现的搜索操作错误的问题。
- 引入sync_counter机制可以避免错误，但会导致物理复制效率下降。
- 使用smo page queue或LogIndex SMO page queue的方法可以解决问题并减少store和restore操作。
- 讨论了使用LogIndex和bw-tree的方法来解决非smo场景下的冲突问题。
- 现有的sync_counter机制在更新时需要持有index x lock，影响物理复制效率。
- sync_counter机制可能导致频繁的store_position和restore_position操作，影响性能。
- 提出了SMO page queue的方法，通过传递SMO page ID来减少不必要的操作。
- LogIndex方法通过带上lsn信息来访问指定版本的Page，避免访问到不存在的Page。
- bw-tree和LogIndex的区别在于内存中保存的Page版本不同。
- Aurora和Socrate也存在类似的问题，使用getPage(lsn)协议可能导致访问到未来页。
- 建议在RO smo page queue中允许读取future page。
- sync_counter机制的本质原因是并行apply redo log时可能读取到中间状态，导致next_page不正确。
➡️
