MySQL原理(十)：主从架构

前言

上一篇介绍了 MySQL 的表分区和分库分表，这一篇将介绍主从架构相关的内容。

主从架构

常见的主从架构模式有四种：

• 一主多从架构：适用于读大于写的场景，采用多个从库来分担数据库系统的读压力。
• 多主架构：适用于读写参半的场景，采用多个主库来承载数据库系统整体的读写压力。
• 多主一从架构：适用于写大于读的场景，采用多个主库分担写压力，单个从库承载读压力。
• 级联复制架构：适用于读大于写的场景，采用单个从节点来分担从库对主库造成的 I/O 压力。

接下来的讨论都是针对最常见的一主多从架构。

主从架构中必须有一个主节点，以及一个或多个从节点，所有的数据都会先写入到主，接着其他从节点会复制主节点上的增量数据，从而保证数据的最终一致性，使用主从复制方案，可以进一步提升数据库的可用性和性能：

• 在主节点宕机或故障的情况下，从节点能自动切换成主节点的身份，从而继续对外提供服务。
• 提供数据备份的功能，当主节点的数据发生损坏时，从节点中依旧保存着完整数据。
• 可以基于主从实现读写分离，主节点负责处理写请求，从节点处理读请求，进一步提升性能。

但无论任何技术栈的主从架构，都会存在致命硬伤，同时也会存在些许问题需要解决：

• 硬伤：木桶效应，一个主从集群中所有节点的容量，受限于存储容量最低的哪台服务器。
• 数据一致性问题：由于同步复制数据的过程是基于网络传输完成的，所以存储延迟性。
• 脑裂问题：从节点会通过心跳机制，发送网络包来判断主机是否存活，网络故障情况下会产生多主。

主从复制

MySQL 集群的主从复制过程梳理成 3 个阶段：

• 写入 Binlog：主库更新本地存储数据，并写 binlog 日志，然后提交事务。
• 同步 Binlog：把 binlog 复制到所有从库上，每个从库把 binlog 写到暂存日志中。
• 回放 Binlog：回放 binlog，并更新存储引擎中的数据。

具体详细过程如下：

1. MySQL 主库在收到客户端提交事务的请求之后，会先更新数据；
2. 数据写入完成后，再去写入 binlog，然后提交事务，返回客户端“操作成功”的响应；
3. 主节点上有一条专门监听 binlog 的 log dump 线程；
4. 当 log dump 线程监听到日志发生变更时，会通知从节点来拉取数据；
5. 从节点有专门的 I/O 线程（io_thread）用于等待主节点的通知，当收到通知时会去请求一定范围的数据；
6. 当从节点在主节点上请求到数据后，会将得到的数据写入到 relay-log 中继