1. 复制架构
┌──────────────┐
│ Client │
└──────┬───────┘
│
┌─────▼─────┐
│ Master │ ← 处理写请求，记录 binlog
│ (主库) │
└─────┬─────┘
│ binlog dump
┌─────────────┼─────────────┐
↓ ↓ ↓
┌────────┐ ┌────────┐ ┌────────┐
│ Slave 1│ │ Slave 2│ │ Slave 3│ ← 读请求
│(IO线程) │ │(IO线程) │ │(IO线程) │
│(SQL线程)│ │(SQL线程)│ │(SQL线程)│
└────────┘ └────────┘ └────────┘
2. 复制模式
2.1 异步复制（Asynchronous）
Client → Master (写入成功) → 立即返回
↓ 后台异步
Slave（可能有延迟）
特点：快，不阻塞客户端，但 Master 宕机时可能丢失未同步数据
MySQL 默认模式
2.2 半同步复制（Semi-Synchronous）
Client → Master (prepare) → 等待至少 1 个 Slave ACK
↓
Slave (收到 relay log)
→ ACK → Master commit → 返回客户端
特点：返回慢一些，但保证至少一个 Slave 已接收数据，降低丢失风险
2.3 组复制（Group Replication）
多主或单主模式，多数派确认后提交（Paxos 协议）。
自动故障检测和切换，数据强一致。
MySQL 5.7+ 内置。
| 模式 | 一致性 | 性能 | 故障场景数据丢失 |
|---|
| 异步 | 最终一致 | 最高 | 可能丢失所有未同步 |
| 半同步 | 至少一个副本 | 中 | 最多丢失一个事务 |
| 组复制 | 强一致 | 较低 | 不丢失（多数派确认） |
3. Binlog
3.1 格式
| 格式 | 内容 | 优点 | 缺点 |
|---|
| STATEMENT | 原始 SQL 语句 | 体积小 | 非确定性函数（UUID/ NOW()）问题 |
| ROW | 行变更前后镜像 | 精确、安全 | 体积大（UPDATE 全表时膨胀） |
| MIXED | 混合策略 | 平衡 | 复杂 |
-- 推荐配置（ROW 格式）
SET GLOBAL binlog_format = 'ROW';
SET GLOBAL binlog_row_image = 'FULL'; -- FULL / MINIMAL / NOBLOB
-- ROW 格式示例
-- UPDATE users SET status = 'active' WHERE id = 1
-- binlog 记录：
-- before_image: id=1, status='inactive'
-- after_image: id=1, status='active'
3.2 GTID（全局事务标识）
GTID = Master_UUID:Transaction_Sequence
示例：
a1b2c3d4-e5f6-7890-abcd-ef1234567890:1-100
优势：
- 自动定位复制位点，避免 file:position 管理
- 故障切换更简单（CHANGE MASTER TO ... AUTO_POSITION=1）
- 避免跳过事务导致的脑裂
4. 复制延迟
4.1 延迟原因
| 原因 | 说明 |
|---|
| 单线程 SQL 线程 | 经典 MySQL 只有 1 个 SQL 线程重放 |
| 大事务 | 一个事务修改大量行，Slave 重放慢 |
| Slave 性能差 | Slave 硬件弱于 Master |
| 锁竞争 | Slave 上也有读请求，与 SQL 线程竞争 |
4.2 并行复制
-- MySQL 5.7+ 并行复制配置
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL slave_parallel_workers = 8; -- SQL 线程数
-- LOGICAL_CLOCK：基于组提交（同一时刻提交的事务可并行）
-- DATABASE：基于库级别并行（不同库的事务并行）
4.3 监控延迟
-- 查看延迟
SHOW SLAVE STATUS\G
-- Seconds_Behind_Master: 0 ← 延迟秒数
-- 更精确的方法（pt-heartbeat）
-- Master 每秒写 heartbeat 表，Slave 计算差值
延伸阅读
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。