MySQL主从复制原理详解

MySQL 主从复制（Master-Slave Replication）是一种数据复制技术，它将一个 MySQL 服务器（主库）的数据实时复制到一个或多个 MySQL 服务器（从库），主要用于实现读写分离、数据备份、高可用性和负载均衡。下面是其核心原理的详细说明：

一、核心流程

主从复制基于 "日志同步" 实现，主要分为三步：

主库写入并记录日志：主库将数据变更写入二进制日志（Binary Log）。
从库拉取日志：从库的 I/O 线程读取主库的二进制日志并写入中继日志（Relay Log）。
从库重放日志：从库的 SQL 线程读取中继日志，重放 SQL 操作，实现数据同步。

二、详细步骤

步骤一：主库记录二进制日志（Binary Log）

当主库执行写操作（INSERT/UPDATE/DELETE 等）时，会将这些操作按顺序记录到二进制日志中。
二进制日志的格式可以是：
- Statement-based ：记录 SQL 语句（**MySQL 5.7 及之前默认，**可能因函数、时间戳等导致数据不一致）。
- Row-based ：记录数据行的变更（**MySQL 8.0及之后默认，**推荐，更安全）。
- Mixed：混合模式，自动选择以上两种。

sql 复制代码

-- 查看当前格式
sql
-- 查看全局和会话级别的 binlog 格式
SHOW GLOBAL VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_format';

-- 查看所有 binlog 相关设置
SHOW VARIABLES LIKE '%binlog%';

步骤二：从库拉取日志（I/O 线程）

从库启动一个 I/O 线程，连接到主库。
主库为每个连接启动一个 Binlog Dump 线程，将二进制日志发送给从库。
从库的 I/O 线程接收日志后，将其写入本地的中继日志（Relay Log）。

步骤三：从库重放日志（SQL 线程）

从库启动一个 SQL 线程，读取中继日志中的事件，并重放 SQL 操作，更新从库数据。
重放完成后，从库会记录已经应用的二进制日志位置，以便断点续传。

三、关键组件

二进制日志（Binlog）：主库的数据变更记录。
中继日志（Relay Log）：从库临时存储主库日志的文件。
**Binlog Dump 线程：**将二进制日志发送给从库的线程
I/O 线程：从库用于拉取主库日志的线程。
SQL 线程：从库用于重放日志的线程（MySQL 5.6+ 支持多线程复制，可并行重放）。

四、复制模式

（1）异步复制（默认）

主库提交事务后，不等待从库响应，直接返回客户端。
优点：性能高。
缺点：可能丢失数据（主库宕机时未同步的日志会丢失）。

（2）半同步复制

主库提交事务后，至少等待一个从库接收并写入中继日志后才返回客户端。
优点：保证数据至少有一个副本，增强数据安全性。
缺点：性能略低于异步复制。

（3）组复制（Group Replication，MySQL 5.7+）

基于 Paxos 协议实现多主同步，所有节点数据强一致。
适用于高可用集群（如 InnoDB Cluster）。

五、配置要点

主库配置

复制代码

ini

# 启用二进制日志
log_bin = mysql-bin
# 设置服务器唯一ID
server_id = 1
# 指定复制的数据库（可选）
binlog_do_db = mydb

从库配置

复制代码

ini

server_id = 2
# 指定主库信息
CHANGE MASTER TO
  MASTER_HOST='主库IP',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='密码',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;
# 启动复制
START SLAVE;

六、常见问题与优化

数据延迟：
- 原因：从库 SQL 线程重放慢、网络延迟、主库并发高。
- 优化：启用多线程复制（slave_parallel_workers）、使用行格式日志、升级硬件。
主从数据不一致：
- 定期校验数据（如 pt-table-checksum 工具）。
- 使用 GTID（全局事务标识） 自动跟踪事务位置（MySQL 5.6+）。
复制中断：
- 常见于主键冲突、从库写入误操作等。
- 可通过 SHOW SLAVE STATUS 查看错误信息，手动修复后执行 START SLAVE。

七、扩展：GTID 复制

GTID（Global Transaction Identifier）为每个事务分配唯一ID，简化故障恢复和主从切换：