MySQL复制通过binlog实现主从数据同步，支持异步、半同步和组复制模式；配置时需启用binlog、设置server-id并创建复制账号；故障时可将延迟最小的从库提升为新主库，并结合MHA工具实现自动切换；通过监控延迟、校验数据一致性、设置只读模式及在从库备份来优化稳定性；定期演练切换流程确保应急能力。
在 MySQL 中使用复制（Replication）是实现业务连续性的重要手段。通过将主服务器的数据实时同步到一个或多个从服务器，可以在主库故障时快速切换服务，减少停机时间，保障系统可用性。
理解 MySQL 复制机制
MySQL 复制基于二进制日志（binlog），主库记录所有数据变更操作，从库通过 I/O 线程读取这些日志并写入中继日志，再由 SQL 线程重放日志内容完成数据同步。常见的复制模式包括：
- 异步复制：默认方式，主库不等待从库确认，性能好但可能丢失少量数据
- 半同步复制：至少一个从库确认接收到日志后主库才提交事务，提升数据安全性
- 组复制（Group Replication）：支持多主模式和自动故障检测，适合高可用架构
配置主从复制保障持续服务
搭建基础复制结构是实现业务连续性的第一步。基本步骤如下：
- 在主库启用 binlog 和 server-id，在 [mysqld] 段添加：
log-bin=mysql-bin
server-id=1 - 创建用于复制的专用账号：
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; - 从库配置唯一 server-id，并执行 CHANGE MASTER TO 指定主库信息
- 启动复制：START SLAVE; 并检查状态是否正常
利用复制实现故障切换
当主库出现故障时，可选择延迟最小的从库提升为新主库。关键操作包括：
- 确认原主库已不可用，避免脑裂
- 在候选从库上执行 STOP SLAVE; 停止复制
- 清除主库信息：RESET MASTER; 和 RESET SLAVE ALL;
- 将其配置为新的主库，并更新其他从库指向新主
建议结合 MHA（Master High Availability）等工具实现自动检测与切换，缩短恢复时间。
优化复制提升业务稳定性
为确保复制稳定运行，需关注以下方面：
- 监控复制延迟（Seconds_Behind_Master），及时发现网络或硬件瓶颈
- 定期校验主从数据一致性，可使用 pt-table-checksum 工具
- 合理设置从库只读模式（read_only=ON），防止误写
- 备份任务尽量在从库执行，减轻主库压力
基本上就这些。通过合理设计复制拓扑并配合监控与切换机制，MySQL 复制能有效支撑业务连续性需求。不复杂但容易忽略的是日常维护和应急演练，定期测试切换流程才能保证真正出问题时不慌乱。
