背景
1、产品的问题点
- PG multi-master 支持不友好
2、问题点背后涉及的技术原理
- PG 支持逻辑复制, 内置了pub、sub订阅功能, 但是针对同一个表只能单向复制, 无法实现双向复制(会有无限循环的问题)
- 无法很好的解决数据冲突问题, 例如:
- 更新操作, 在更新数据同步到目标节点之前, 目标节点对同一条记录也执行了更新操作, 这个问题会导致数据不一致.
3、这个问题将影响哪些行业以及业务场景
- multi-master 被应用于什么业务场景?
- 高可用场景, 多写可以满足无缝切换、升级需求.
- 全球化、或者单元化部署的业务, 在多个IDC的应用可以就近访问本地数据库, 多个IDC的数据库通过星型复制实现统一整体.
4、会导致什么问题?
- 无法支持多实例多写, 所有写操作需要发往中心数据库, 可能产生较高的响应延迟.
5、业务上应该如何避免这个坑
- 可以业务自己开发同步工具, 通过增加事务标记来标示从wal中解析出来逻辑记录的初始节点. 避免无限循环的问题.
- 使用一些复制工具来实现multi-master
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 增加了复杂度
- 工具本身的可靠性无法保障
- 数据复制冲突没有很好的解决方案
- 全局序列没有很好的解决方案
7、数据库未来产品迭代如何修复这个坑
- 希望内核层支持完备的multi-master解决方案
