MySQL 主从复制（Replication）原理深度分析

MySQL 主从复制是数据库高可用、读写分离和负载均衡的基础技术，下面我将从底层机制到实现细节全面解析其工作原理。

一、核心架构与组件

1. 角色划分

• 主库（Master）：接收所有写操作，记录二进制日志
• 从库（Slave）：复制主库数据，可处理读请求

2. 核心线程

线程	所属节点	职责
Binlog Dump Thread	主库	读取binlog并发送给从库
I/O Thread	从库	接收主库的binlog并写入relay log
SQL Thread	从库	读取relay log并执行SQL

二、复制流程详解

1. 二进制日志记录（主库）

graph TD
    A[客户端写请求] --> B[主库执行事务]
    B --> C[写入存储引擎]
    B --> D[写入binlog文件]

• binlog格式：
• STATEMENT：记录SQL语句（5.7默认）
• ROW：记录行数据变化（8.0默认）
• MIXED：混合模式

2. 日志传输阶段

graph LR
    Master -->|Binlog Dump| Slave_IO
    Slave_IO -->|写入| RelayLog

• 关键参数：
• server-id：集群内唯一标识
• log_bin：启用二进制日志
• sync_binlog：控制刷盘策略（1最安全）

3. 中继日志应用（从库）

graph TD
    RelayLog --> SQL_Thread
    SQL_Thread -->|执行SQL| SlaveDB

• 并行复制：
• 5.6+：基于库级别的并行
• 5.7+：基于组提交的并行
• 8.0+：基于writeset的并行复制

三、复制类型对比

类型	原理	优点	缺点	适用场景
异步复制	主库不等待从库确认	性能最好	数据可能丢失	允许延迟的非关键业务
半同步复制	至少一个从库确认	平衡性能与安全	比异步稍慢	常规业务场景
组复制	基于Paxos协议	强一致性	性能开销大	金融级关键业务

四、关键实现机制

1. GTID复制（Global Transaction Identifier）

-- 启用GTID
gtid_mode=ON
enforce_gtid_consistency=ON

-- GTID格式
UUID:TransactionID

优势：

• 自动定位复制位置
• 简化故障恢复
• 支持多源复制

2. 复制过滤机制

# 主库过滤
binlog-do-db = db1
binlog-ignore-db = db2

# 从库过滤
replicate-do-db = db1
replicate-ignore-db = db2

3. 延迟监控

SHOW SLAVE STATUS\G
-- 关键指标：
-- Seconds_Behind_Master: 复制延迟秒数
-- Slave_IO_Running: I/O线程状态
-- Slave_SQL_Running: SQL线程状态

五、典型问题与解决方案

1. 数据不一致

解决方案：

• 使用pt-table-checksum检测差异
• 通过pt-table-sync修复数据
• 考虑使用ROW格式binlog

2. 复制延迟

优化方案：

# 从库配置优化
slave_parallel_workers=8
slave_parallel_type=LOGICAL_CLOCK

3. 主从切换

安全切换步骤：

1. 主库设置read_only
2. 等待从库追平
3. 提升从库为主库
4. 其他从库切换复制源

六、性能优化实践

1. 硬件层面

• 主库：高性能SSD，保证binlog写入速度
• 从库：与主库同等配置，避免成为瓶颈

2. 参数调优

# 主库
sync_binlog=1
innodb_flush_log_at_trx_commit=1

# 从库
read_only=ON
skip_slave_start=ON
log_slave_updates=ON  # 级联复制需要

3. 架构设计

• 级联复制：减轻主库压力
• 多线程复制：提升从库应用速度
• 读写分离中间件：如MyCat/ProxySQL

七、版本演进对比

版本	重大改进
5.5	半同步复制
5.6	GTID, 多线程复制
5.7	组复制, 在线变更复制源
8.0	原子DDL, 性能提升

理解MySQL复制原理对于构建可靠数据库架构至关重要。建议在实际环境中通过SHOW PROCESSLIST和性能监控工具持续观察复制状态，根据业务特点选择合适的复制策略。