MySQL复制容灾通过主从架构实现，主库记录binlog，从库同步数据；需配置唯一server-id、启用binlog、创建复制账号，并启动从库复制进程。
MySQL 使用复制（Replication）做容灾是一种常见且有效的策略，通过将主数据库的数据实时同步到一个或多个从库，可以在主库发生故障时快速切换到从库，保障服务的可用性。以下是实现 MySQL 复制容灾的关键步骤和注意事项。
配置主从复制
容灾的基础是搭建稳定的主从复制结构。通常采用一主多从架构，其中一个从库作为热备用于故障切换。
说明：
主库（Master）负责处理写操作，并将数据变更记录到二进制日志（binlog）。从库（Slave）通过 I/O 线程读取主库的 binlog，并由 SQL 线程重放，实现数据同步。
基本配置步骤：
- 在主库启用 binlog 和 server-id，确保 log-bin 和 server-id 唯一
- 在从库设置唯一的 server-id，并配置主库连接信息（CHANGE MASTER TO）
- 主库创建用于复制的账号并授权 REPLICATION SLAVE
- 从库启动复制：START SLAVE
监控复制状态
复制延迟或中断会直接影响容灾能力，必须持续监控复制的健康状态。
关键命令：
- 在从库执行 SHOW SLAVE STATUSG，关注以下字段：
- Slave_IO_Running 和 Slave_SQL_Running 应为 Yes
- Seconds_Behind_Master 显示延迟时间，应尽量接近 0
- 查看 Last_Error 判断是否有错误中断
建议部署自动化监控工具（如 Prometheus + MySQL Exporter 或 Zabbix）实时告警异常。
实现自动故障转移
当主库宕机时，需要快速将一个从库提升为主库，并重新指向应用流量。
常用方案：
- 使用 MHA（Master High Availability）工具实现自动检测和切换
- MHA 能自动选择最新的从库进行提升，并修复其他从库的复制关系
- 配合 VIP（虚拟 IP）或代理层（如 MaxScale、ProxySQL）减少应用修改
手动切换流程包括：确认主库失效 → 停止从库 IO 线程 → 检查数据一致性 → 提升从库为新主库 → 重新配置剩余从库指向新主库。
定期演练与数据保护
容灾系统必须经过验证才能确保有效。
- 定期模拟主库宕机，测试切换流程和恢复时间
- 保留多个从库，一个用于容灾，另一个用于备份或延迟复制（应对误删）
- 启用 relay-log 持久化和 sync_relay_log 防止从库崩溃丢数据
- 结合物理备份（如 Percona XtraBackup）提供更完整的数据保护
基本上就这些。只要主从复制稳定、监控到位、切换流程清晰，MySQL 复制就能构建可靠的容灾体系。关键是平时准备充分，出问题时不慌。