MySQL 复制原理与配置

核心定义 MySQL 主从复制通过主库 binlog、从库 IO 线程、relay log 和 SQL 线程实现数据异步同步。GTID 模式进一步用全局事务编号替代传统 file + position 位点，降低主从切换和故障恢复复杂度。

1. 主从复制核心组件

2. 复制流程

主库提交事务
  ↓
写入 binlog
  ↓
主库 dump thread 发送 binlog event
  ↓
从库 IO thread 接收并写入 relay log
  ↓
从库 SQL thread 重放 relay log
  ↓
从库数据追上主库

该流程默认是异步复制，主库提交成功不等于从库已经执行完成。

3. 传统位点复制

传统复制依赖 binlog 文件和 position。

主库查看位点：

SHOW MASTER STATUS;

从库配置：

CHANGE MASTER TO
  MASTER_HOST='10.0.0.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;

启动复制：

START SLAVE;

传统方式需要准确记录位点，主从切换时容易出错。

4. GTID 复制

GTID 复制使用全局事务集合自动定位复制起点。

配置前置参数：

[mysqld]
server_id=1
log_bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON

从库配置自动定位：

CHANGE MASTER TO
  MASTER_HOST='10.0.0.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_AUTO_POSITION=1;

MySQL 8.0 新语法中可使用 SOURCE / REPLICA 相关命令，但很多生产环境仍保留 MASTER / SLAVE 旧语法。

5. 复制账号授权

主库创建复制账号：

CREATE USER 'repl'@'%' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

生产环境应限制来源 IP，避免使用 % 暴露复制账号。

6. 查看复制状态

SHOW REPLICA STATUS\G

旧版本：

SHOW SLAVE STATUS\G

重点字段：

7. 常见复制类型

8. 生产配置建议

• 每个实例配置唯一 server_id。
• 主库开启 log_bin。
• GTID 场景开启 gtid_mode 与 enforce_gtid_consistency。
• 级联复制开启 log_slave_updates。
• 复制账号限制来源 IP。
• 配置 binlog 保留时间，避免从库延迟后无法追赶。
• 监控复制线程、复制延迟和错误字段。

9. 面试回答模板

标准回答 MySQL 主从复制基于 binlog 实现。主库提交事务后写入 binlog，主库 dump 线程将日志事件发送给从库；从库 IO 线程接收后写入 relay log，SQL 线程再重放 relay log 写入从库数据。传统复制依赖 binlog file 和 position，GTID 复制使用全局事务编号集合自动定位复制起点，更适合主从切换和故障恢复。排查复制状态时重点关注 IO 线程、SQL 线程、复制延迟、Retrieved_Gtid_Set、Executed_Gtid_Set 以及 Last_IO_Error、Last_SQL_Error。

关联文档

• GTID 集合详解：理解 GTID 集合在复制定位中的作用。
• MySQL 主从同步故障排查：排查复制线程中断和延迟。
• MySQL binlog 保留时间与清理：理解 binlog 保留策略对复制恢复的影响。