多主复制的适用场景-多IDC

Posted 2022-08-07 JavaEdge.

3 多主复制

之前都是单主的主从复制架构，主从复制有个明显缺点：只有一个主节点，而所有写都必须通过它¹。万一和主节点之间的网络中断而导致无法连接到主节点，主从复制方案就影响所有DB写入操作。

对主从复制模型进行扩展，则可配置多个主节点，每个主节点都能处理写，后面复制的流程类似：处理写的每个【主节点】都必须将该数据更改转发到所有其他节点 。这就是多主节点（也称为主-主，或主动/主动）复制。 此时，每个主节点还同时扮演其他主节点的从节点。

3.1 适用场景

在一个IDC内部使用多个主节点没啥大意义，因复杂性远超带来的好处。 但某些case，多活配置也合理：

3.1.1 多IDC

为容忍整个IDC级别故障或更接近用户，可将DB的副本横跨多个IDC。而若使用常规的主从复制模型，主节点必须位于其中一个IDC，且所有写请求都须经过该IDC。

有了多主节点复制模型，则能在每个IDC都配置主节点，如图-6所示基本架构：

• 在每个IDC内，采用主从复制
• IDC之间，由各个IDC的主节点负责和其它IDC的主节点进行数据交换、更新

比较多数据中心时，单主和多主：

性能

• 单活，每个写入须穿过互联网，进入主节点数据中心。这可能会大大增加写延迟，并违背设置多数据中心的初心（就近访问）
• 多活，每个写操作都能在本地IDC快速响应，然后采用异步复制将变化同步到其它IDC。因此，对上层应用有效屏蔽了IDC之间的网络延迟，使得终端用户所体验到的性能更好

容忍数据中心停机

主从复制下，若M所在IDC故障，必须切换至另一个IDC，将其中的1个从节点提升为M。多主模型中，每个IDC则可独立于其他IDC继续运行，发生故障的数据中心在恢复之后更新到最新状态。

容忍网络问题

IDC之间的通信通常经由广域网，大多不如IDC内的本地网络可靠。单主配置对这数据中心间的连接问题非常敏感，因为通过这个连接进行的写操作是同步的。采用异步复制功能的多活配置通常能更好地承受网络问题：临时的网络中断并不会妨碍正在处理的写入。

有些数据库默认情况下支持多主配置，但使用外部工具实现也很常见，如mysql的Tungsten Replicator。

尽管多主复制有这些优势，但也有一个很大的缺点：两个不同IDC可能会同时修改相同的数据，写冲突必须解决（图-6中conflict resolution）。

由于多主复制在许多数据库中只是新增功能，所以还存在微妙的配置缺陷，与其他数据库功能如自增主键、触发器、完整性约束之间，交互有时会出现意外。因此，很多人觉得多主复制比较危险，应尽可能避免。

---

1. 若DB还采用分区，不同分区可能将主副本放在不同节点，但对给定的某分区，则只有一个主节点 ↩︎