**一、选择合适的复制模式**
**1. 基于语句的复制（Statement-Based Replication, SBR）**
- **原理**：主库记录 SQL 语句到 binlog，从库重放相同语句。
- **优点**：binlog 体积小，网络传输开销低。
- **缺点**：非确定性函数（如 `NOW()`、`UUID()`）可能导致主从不一致。
- **适用场景**：纯事务操作（如 `INSERT/UPDATE` 带明确条件）。
**2. 基于行的复制（Row-Based Replication, RBR）**
- **原理**：主库记录行变更详情（如 `id=1` 的记录从 `name=A` 变为 `name=B`）。
- **优点**：确保主从数据绝对一致，支持所有 SQL 语句。
- **缺点**：binlog 体积大，性能略低。
- **适用场景**：包含非确定性函数的事务、涉及外键的跨表操作。
**3. 混合复制（Mixed-Based Replication, MBR）**
- **原理**：自动选择 SBR 或 RBR（默认优先 SBR，遇非确定性函数时切换 RBR）。
- **配置**：
```sql
-- 在主库配置文件中设置
binlog_format = MIXED
```
**二、关键参数配置**
**1. 主库参数**
ini
# 开启二进制日志
log-bin = mysql-bin
server-id = 1 # 唯一标识，通常为 IP 后三位
# 推荐配置
binlog_format = ROW # 使用 RBR 模式
sync_binlog = 1 # 每次事务提交同步 binlog 到磁盘
innodb_flush_log_at_trx_commit = 1 # 每次事务提交刷新日志到磁盘
expire_logs_days = 7 # binlog 过期时间，避免占满磁盘
**2. 从库参数**
ini
server-id = 2 # 唯一标识，与主库不同
# 推荐配置
relay-log = relay-bin # 中继日志
log_slave_updates = 1 # 从库更新也记录 binlog（用于级联复制）
read_only = 1 # 从库只读（防止误写）
**三、架构设计与最佳实践**
**1. 事务隔离级别选择**
- **推荐 `REPEATABLE-READ`（默认）**：可避免脏读、不可重复读，但无法防止幻读。
- **若需严格一致性**：使用 `SERIALIZABLE`（但会降低并发）。
**2. 避免大事务**
- 大事务会占用锁资源，延长主从同步延迟。
```sql
-- 反例：一次性更新 100 万条记录
UPDATE users SET status = 'active' WHERE created_at < '2023-01-01';
-- 正例：分批更新
WHILE (SELECT COUNT(*) FROM users WHERE created_at < '2023-01-01' AND status != 'active') > 0 DO
UPDATE users SET status = 'active' WHERE created_at < '2023-01-01' AND status != 'active' LIMIT 1000;
END WHILE;
```
**3. 跨库事务处理**
- **避免跨主库事务**：若业务需要，使用分布式事务框架（如 Seata、XA 协议）。
- **外键约束**：确保主从库都启用 `foreign_key_checks = 1`，避免数据不一致。
**四、监控与故障处理**
**1. 监控主从延迟**
sql
-- 在从库执行，检查 Seconds_Behind_Master
SHOW SLAVE STATUS\G
- **理想值**：`Seconds_Behind_Master = 0`。
- **异常处理**：若延迟持续超过阈值（如 5 秒），自动将读请求切回主库。
**2. 主从一致性验证**
- **定期校验工具**：使用 `pt-table-checksum` 对比主从数据。
- **业务层校验**：关键业务（如支付）在事务提交后强制读主库。
**3. 故障恢复流程**
- **主库崩溃**：提升从库为主库，其他从库指向新主库。
- **从库崩溃**：重启后自动追赶主库进度。
**五、常见问题与解决方案**
| 问题 | 原因 | 解决方案 |
|-----------------------|----------------------------------------------------------------------|--------------------------------------------------------------------------|
| 主从数据不一致 | 使用 SBR 模式且包含非确定性函数（如 `UUID()`） | 改用 RBR 模式 |
| 从库复制中断 | 网络波动、binlog 文件损坏 | 重启从库复制线程，必要时从主库全量备份恢复 |
| 大事务导致延迟 | 长事务持有锁时间过长，阻塞复制进程 | 拆分大事务为多个小事务 |
| 从库写入导致冲突 | 未设置 `read_only = 1` 或业务代码误写 | 强制从库只读，应用层严格分离读写数据源 |
**总结**
确保 MySQL 主从复制场景下事务正常运行的核心是：
1. **选择 RBR 复制模式**：保证数据绝对一致。
2. **合理配置参数**：同步 binlog 到磁盘，防止数据丢失。
3. **优化事务设计**：避免大事务和跨库事务。
4. **实时监控与快速恢复**：及时发现并处理延迟和故障。
通过以上策略，可以在保证事务 ACID 特性的同时，实现读写分离的性能优化。