MySQL 复制原理与配置
本文内容整理自 MySQL 8.0 官方文档第十七章，涵盖复制核心原理与实践配置。
一、复制概述
复制使来自一台 MySQL 数据库服务器（源）的数据能够复制到一台或多台 MySQL 数据库服务器（副本）。
复制方式
| 方式 | 说明 |
|---|---|
| 异步复制 | 默认模式，副本无需永久连接即可从源接收更新 |
| 半同步复制 | 至少一个副本确认收到事务后才提交 |
| 延迟复制 | 副本故意落后于源至少指定的时间 |
复制方法
| 方法 | 说明 | 优势 |
|---|---|---|
| 传统方法 | 基于二进制日志文件位置，需同步日志文件和位置 | 兼容旧版本 |
| GTID 方法 | 全局事务标识符，无需处理日志文件位置 | 简化复制管理，保证一致性 |
复制格式
| 格式 | 说明 | 适用场景 |
|---|---|---|
| 基于语句的复制（SBR） | 复制 SQL 语句 | 简单操作，日志量小 |
| 基于行的复制（RBR） | 复制数据行变更 | 默认模式，数据一致性好 |
| 混合复制（MBR） | 自动在 SBR 和 RBR 间切换 | 兼顾两者优点 |
二、复制实现原理
核心组件
源端写入 → 二进制日志（binlog）
↓ dump 线程推送
副本 IO 线程接收 → 写入中继日志（relay log）
↓ SQL 线程读取
副本重放 SQL → 数据同步完成复制线程
| 线程 | 位置 | 职责 |
|---|---|---|
| Binlog Dump 线程 | 源端 | 读取 binlog 并推送给副本 |
| IO 线程 | 副本端 | 接收 binlog 并写入 relay log |
| SQL 线程 | 副本端 | 读取 relay log 并在副本上重放 |
中继日志（Relay Log）
- 副本从源接收的 binlog 事件先写入 relay log
- SQL 线程从 relay log 读取并执行
- relay log 使用与 binlog 相同的格式
GTID 复制原理
GTID（全局事务标识符） = server_uuid:transaction_id
- 源上提交的每个事务被分配一个唯一 GTID
- 副本通过 GTID 自动追踪已应用的事务
- 故障切换时，副本自动跳过已应用的事务，不会重复执行
三、复制配置步骤
基于二进制日志文件位置的复制
- 源端配置：开启 binlog，设置 server-id
- 创建复制用户：
CREATE USER ... IDENTIFIED BY ...; GRANT REPLICATION SLAVE; - 获取源端 binlog 坐标：
SHOW MASTER STATUS; - 副本配置：
CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE=..., SOURCE_LOG_POS=...; - 启动复制：
START REPLICA;
基于 GTID 的复制
- 开启 GTID：
gtid_mode=ON,enforce_gtid_consistency=ON - 配置步骤同传统方法，但使用 GTID 自动追踪
- 故障切换简化：新源无需重新计算 binlog 位置
四、复制安全
- 复制默认不加密，建议使用 SSL/TLS 加密复制连接
- 使用
SOURCE_SSL_*参数配置加密连接 - 复制用户应仅授予最小必要权限
五、注意事项
| 类型 | 说明 |
|---|---|
| 版本兼容 | 源版本 ≤ 副本版本，主版本号必须相同 |
| DDL 安全 | DDL 语句在基于行的复制中可能引起不一致 |
| 过滤规则 | replicate_do_db / replicate_ignore_db 等过滤规则需谨慎使用 |
| GTID 约束 | CREATE TABLE ... SELECT 在 GTID 模式下不被支持 |
| 存储引擎 | InnoDB 是推荐的事务型引擎 |
关联文档
- MySQL 基础知识面试题 — MySQL 基础概念
- MySQL binlog 保留时间与清理 — binlog 管理策略
- MySQL 主从复制备份方式对比 — 备份方式对比
- MySQL 高可用方案 — 高可用架构
- 面试题/MySQL 日志与复制 — 复制面试题