背景
1、产品的问题点
2、问题点背后涉及的技术原理
- PG 物理流复制协议支持将wal数据发送给下游节点, 实现物理的增量同步.
- 每个下游节点只能配置一个上游节点.
- PG 的一个上游节点可以配置多个下游节点, 下游节点还可以配置集联的下游节点.
- 在一个WAL复制的集群拓扑中, 每个节点的WAL文件内容是一样的, 所以理论上可以相互补位复制.
3、这个问题将影响哪些行业以及业务场景
- 通用(使用了物理流复制的场景: 高可用、只读实例、容灾等)
4、会导致什么问题?
- 如果上游节点挂了, 下游节点就接收不到wal日志, 需要及时改流复制的连接配置, 连接到活着的节点. 如果改配置不及时可能导致新的上游节点WAL已清理, 需要重建或rewind修复下游.
- 如果上游节点是HA架构, 一旦发生主从切换, 下游节点可能和上游节点的WAL发生分叉, 导致下游节点需要重建或rewind修复.
5、业务上应该如何避免这个坑
- 及时发现, 人工处理. 或者有自动化运维工具进行发行和处理.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
7、数据库未来产品迭代如何修复这个坑
- standby 支持多上游节点, 优先从从库接收wal, 主从切换不影响下游的只读实例. (开源版本有一部分概率上游节点发生HA切换后可能需要重新搭建只读库)
- 拓扑感知, 可以在多个从库之间自动转发wal, 确保wal平衡后再切换. 可以确保整个集群在发生故障时可以应用更多的wal、避免出现分叉. 《DB吐槽大会,第72期 - PG wal 联网协议不够发达》