MySQL 主从复制

原创已于 2025-10-30 16:20:14 修改 · 784 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库 #主从复制

于 2025-10-30 16:17:32 首次发布

一、基本概念

1、简介

在实际生产环境中，为了解决 MySQL 服务的单点和性能问题，使用 MySQL 主从复制架构是非常常见的一种方案。在主从复制架构中，将 MySQL 服务器分为主服务器（Master）和从服务器（Slave）两种角色，主服务器负责数据写入（insert，update，delete，create 等），从服务器负责提供查询服务（select 等）。MySQL 主从架构属于向外扩展方案，主从节点都有相同的数据集，其基于二进制日志的单向复制来实现，复制过程是一个异步的过程。

2、主从复制的优点

负载均衡读操作：将读操作进行分流，由另外一台或多台服务器提供查询服务，降低 MySQL 负载，提升响应速度；
数据库备份：主从节点上都有相同的数据集，从而也实现了数据库的备份；
高可用和故障切换：主从架构由两个或多个服务节点构成，在某个节点不可用的情况下，可以进行转移和切换，保证服务可用；
MySQL升级：当 MySQL 服务需要升级时，由于主从架构中有多个节点，可以逐一升级，而不停止服务。

3、主从复制的缺点

数据延时：主节点上的数据需要经过复制之后才能同步到从节点上，这个过程需要时间，从而会造成主从节点之间的数据不一致；
性能消耗：主从复制需要开启单独线程，会消耗一定资源；
数据不对齐：如果主从复制服务终止，而且又没有第一时间恢复，则从节点的数据一直无法更新。

4、架构应用

依赖于 MySQL 服务的应用程序连接代理，代理将应用程序的写操作分发到 Master 节点，将读操作分发到从节点，如果有多个从节点，还可以根据不同的调度算法来进行分发。

二、主从复制原理

主从复制是异步执行的分布式过程，分为 “日志写入”、“日志同步”、“日志重放” 三个阶段，每个阶段对应特定的进程和文件。

1、主库将变更写入二进制日志（binlog）

主库执行 INSERT、UPDATE、DELETE 等写操作后，会先将变更记录到二进制日志（Binary Log，简称 binlog），再提交事务。

关键进程：

Master 节点上会为每一个 Slave 节点上的 IO 线程（I/O Thread）启动一个 binlog dump 线程，用来向其提供本机的二进制事件。

关键文件：

binlog：主库的核心日志文件，记录所有数据变更的详细指令（如 “在表 t1 中插入 id=1 的行”），是复制的 “数据源”。
binlog.index：binlog 的索引文件，记录所有 binlog 文件的名称和顺序，方便主库管理日志文件。

2、从库 IO 线程复制 binlog 到中继日志（relaylog）

Slave 节点上的 I/O thread 向 Master 节点请求该节点上的二进制事件，并将得到的内容写到当前节点上的 replay log （简称 relaylog）中。

关键进程：

主库：binlog dump 线程响应从库 I/O Thread 的请求，按顺序读取 binlog 内容并发送给从0库。
从库：I/O Thread 接收主库发送的 binlog 数据，将其写入本地的中继日志 relaylog 。

关键文件：

relaylog：从库的 “中间日志”，格式与 binlog 完全一致，作用是避免直接修改 binlog 导致主从同步冲突。
master.info：从库保存的主库连接信息（如主库 IP、端口、复制账号密码、已同步的 binlog 文件名和位置）。
relay-log.info：从库保存的中继日志执行进度（如已经复制的当前二进制日志和本地relaylog日志的对应关系）。

注意：MySQL8.0 取消 master.info 和 relay-log.info文件

在 MySQL 8.0 中，复制配置和状态信息不再直接存储在磁盘上的 master.info 和 relay-log.info 文件中。相反，这些信息被存储在数据字典表（如 mysql.slave_master_info 和mysql.slave_relay_log_info）中。这些表提供了与旧文件相同的信息，但具有更好的性能和可靠性，因为它们是由 MySQL 服务器直接管理的。由于这些文件不再使用，因此与这些文件相关的配置选项（如 master_info_repository 和 relay_log_info_repository）在 MySQL 8.0 中已被弃用。

3、从库 SQL 线程执行中继日志中的语句

Slave 节点上的 SQL Thread 实时监测 replay log 内容是否有更新，如果更新，则将该文件中的内容解析成 SQL 语句，还原到 Slave 节点上的数据库中去，这样来保证主从节点之间的数据同步。

关键进程：

从库 SQL Thread 按顺序解析 relaylog 中的 SQL 指令，在从库本地重新执行这些指令，最终实现主从数据一致。SQL Thread 与 I/O Thread 是独立的，即使 SQL Thread 执行缓慢（如从库压力大），I/O Thread 仍会继续同步 binlog，避免主库压力堆积。

三、主流复制架构

1、多从复制

核心特点：

1 个主库 + N 个从库（N≥2），一主多从，所有从库直接从主库同步 binlog。主库仅负责写，从库负责读。

适用场景：

读多写少（如电商商品详情页、新闻资讯）；需要扩展读性能，且从库数量较少。

2、级联复制

核心特点：

1 个主库 → 1 个 “中间从库” → N 个 “下游从库”；下游从库从中间从库同步 binlog，不直接连主库。

适用场景：

从库数量多的场景，减少主库的 binlog dump 线程数量，降低主库网络和 CPU 压力。

3、多主复制

核心特点：

N 个主库（N≥2），每个主库既是主库也是其他主库的从库；支持在任意主库写入，数据互相同步。

适用场景：

写入压力分散场景（如分库分表架构）

4、半同步复制

异步复制是 MySQL 默认的复制模式，半同步复制是其增强版，核心差异在于 “主库是否等待从库确认”。

默认情况下，MySQL 中的复制是异步的，当客户端程序向主节点中写入数据后，主节点中数据落盘，写入 binlog 日志，然后将 binlog 日志中的新事件发送给从节点，便向客户端返回写入成功，而并不验证从节点是否接收完毕，也不等待从节点返回同步状态，这意味着客户端只能确认向主节点的写入是成功的，并不能保证刚写入的数据成功同步到了从节点。此复制策略下，如果主从同步出现故障，则有可能出现主从节点之间数据不一致的问题。甚至，如果在主节点写入数据后没有完成同步，主节点服务当机，则会造成数据丢失。

半同步复制是当客户端程序向主节点中写入数据后，主节点中数据落盘，写入 binlog 日志，然后将 binlog 日志中的新事件发送给从节点，等待所有从节点中有一个从节点返回同步成功之后，主节点就向客户端返回写入成功。此复制策略尽可能保证至少有一个从节点中有同步到数据，也能尽早的向客户端返回写入状态。

核心特点：

基于异步复制改造，主库执行写操作后，需等待至少 1 个从库的 I/O Thread 确认收到 binlog，才向客户端返回 “成功”。

适用场景：

数据安全性要求高的场景（如金融交易、支付系统），不允许因主库宕机导致数据丢失。

半同步复制的优势（对比异步复制）：

数据一致性更高：主库会等待从库 I/O Thread 确认 “已收到 binlog”，避免主库宕机后，未同步的 binlog 丢失（异步复制可能出现主库写成功但从库未同步的情况）。
故障恢复更可靠：当主库故障需要切换到从库时，半同步复制的从库数据更完整，减少数据恢复的工作量和风险。

半同步复制的不足（对比异步复制）：

主库性能损耗：主库需等待从库的确认响应，会增加写操作的延迟（延迟时间取决于主从网络带宽和从库 IO 线程效率），高并发写场景下影响更明显。
依赖网络稳定性：若主从网络中断，主库会一直等待从库确认，导致写操作阻塞（可配置超时时间，超时后自动降级为异步复制）。
仅保证 “日志收到”，不保证 “日志执行”：半同步仅确认从库 I/O Thread 收到 binlog，不保证 SQL Thread 已执行完 relaylog，仍可能存在主从数据延迟。