来源 | 君哥聊技术(ID:gh_1f109b82d301) 双主架构是 MySQL 常见的一种架构模式,它的特点是有两个主节点对外提供服务,并且这两个主节点互为主备。今天来学习一下双主架构。
1 双主复制 这种架构的特点配置两个主库,每个主库都提供读写服务,并且这两个主库互为主备。如下图:
在 M1 写入的数据要同步到 M2,在 M2 写入的数据要同步到 M1。这种两个主库同时支持写入,这种架构模式一个明显的优势写入效率高。比如一个应用在不同的城市部署了两个主节点,请求可以就近选择写入数据库。
但这种架构在数据同步时很容易出问题。 案例一:M1 和 M2 同时收到一张表的插入请求,这张表是自增主键,两张表插入后主键相同。这时发生数据同步,这条插入语句在 binlog 里面记录的是 row 格式,同步时发生主键冲突。
MySQL binlog 有三种格式:
MIXED:STATEMENT 和 ROW 格式的结合,MySQL 会根据 SQL 语句特性选择使用 STATEMENT 还是 ROW 格式。 MySQL 5.0 后可以通过设置 auto_increment_increment 和 auto_increment_offset 这两个选项来解决这个问题。
案例二:在 M1 上执行了一条语句,生成 binlog 后发给 M2 进行同步,M2 执行完成后又生成 binlog 同步给 A,导致一条语句循环复制。
这个问题的解决方法是要求 M1 和 M2 的 server id不相同,M1 产生的 binlog 记录 server id 是 M1,M2 执行同步时生成的 binlog 也记录 server id 为 M1。这样同步给 M1 是,M1 判断到 server id 跟自己相同,就丢弃这个日志,不做同步。
案例三:同步过程中会有数据不一致的问题。比如用户 xiaoming 的账户余额是 100。M1 执行了 update 操作把账户余额更新成 150,M2 执行了 update 操作更新成 130。
解决这种数据不一致问题的一个思路是严格划分数据和设置权限,比如案例中小明的所有数据只能在 M1 上操作。
案例四:因为节点发生故障,M1 不能复制了,但是应用可以写数据库,M2 能正常写和复制,这个问题就很难解决了。
解决这个问题,需要给 M1 和 M2 配置从节点,主节点故障后切换到从节点进行工作。
2 主备复制 这个架构模式的特点是双主节点中,同一时刻只有一个主节点提供写服务,另一个主节点只能提供读服务。如下图:
这个架构相当于比单主节点架构多了一个热备,有如下优势:
因为 M1 和 M2 配置对称,切换主备比较容易;
当然,主备架构也有缺点,那就是写性能不能得到提升。
3 主主架构拥有备库 主主架构中每个主库也可以拥有备库,如下图:
这种配置为每个主库增加了一个备份,可以防止单点故障,同时备库也可以处理读请求,提高数据库整体读效率。
这个架构的缺点是增加了机器成本。
4 环形复制 环形复制架构是 MySQL 集群中拥有多个主库,主库之间形成一个环形,前面一个节点是当前节点的主库,当前节点是前面节点的备库,也是后面一个节点的主库。如下图:
环形复制这种架构其实并不推荐,因为它很难做到故障转移,高可用特性依赖于每个节点不出故障。但是如果一个节点出了故障,去掉这个节点,这个节点产生的 binlog 将一直循环复制下去,因为只有通过这个节点的 server id 才能做出判断停止复制。
5 总结 本文介绍了 MySQL 双主架构的多种复制架构,双主架构需要注意解决循环复制、单点故障问题,同时做好数据权限划分。