复制的拓扑结构
1. 常见拓扑结构
- 环形拓扑：每个节点从前一个节点接收写请求，并将写请求转发给下一个节点。这种结构常见于 MySQL 默认配置，但存在节点故障可能影响数据复制的缺点。
- 星形拓扑：一个主节点（中心节点）负责将写请求转发给所有其他节点。此结构比较简单，但有可能单点故障导致系统无法正常工作。
- 全部到全部拓扑：每个主节点将自己的写请求同步到所有其他节点。这种拓扑结构提供了较高的容错性，但会受到不同网络链路速度不一致的问题影响。
2. 拓扑结构的优缺点
- 环形和星形拓扑的问题：
- 依赖于多个节点之间的中转，写请求必须经过多个节点才能传播到所有副本。
- 节点故障时，复制日志的转发会受影响，通常需要手动重新配置拓扑结构。
- 全部到全部拓扑的优势：
- 节点之间的消息可以沿着不同路径传播，提高容错性。
- 性能问题：
- 环形和星形拓扑中，某些网络链路可能比其他链路更快，导致复制日志的顺序问题。例如，客户端 A 先向主节点 1 插入一行数据，而客户端 B 在主节点 3 上更新了该行数据。如果网络问题导致主节点 2 接收到了错误的日志顺序，可能会导致数据不一致。
3. 写请求顺序问题
在多主节点复制中，写请求的传播顺序非常重要。例如：
- 客户端 A 向主节点 1 插入数据后，客户端 B 在主节点 3 更新该数据。如果主节点 2 接收到了错误的日志顺序，可能会先收到更新操作，再收到插入操作，导致数据库处于不一致状态。
4. 因果关系问题
为了解决上述问题，需要确保写请求的顺序正确，特别是插入操作应当先于更新操作。为此，不能仅仅依靠时间戳，因为时钟同步问题会影响日志的顺序。
5. 解决方法
-
版本向量技术：这种技术可以帮助确保日志消息按照正确的顺序传播，并解决因网络延迟引起的顺序错误。
-
因果排序：一些多主节点复制系统（如 PostgreSQL BDR）尚未实现因果排序的写操作，这意味着它们不能自动处理因顺序错误引起的冲突。