SQL灾备方案的核心是保障数据不丢、服务不断，主备复制与切换是其中最常用也最关键的手段。设计时不能只看同步速度，更要关注一致性、切换可靠性与运维可操作性。
主备复制的关键配置要点
主备复制不是开个参数就完事，几个关键点必须明确：
- 复制模式选对：异步复制延迟低但可能丢数据；半同步能平衡可用性与一致性，建议生产环境默认启用（需至少一个备库应答）；全同步严格但影响写入性能，适合金融类强一致场景。
- GTID必须开启：避免基于文件+位置的复制在故障后难以定位同步点，GTID让主备切换、链路重建更可靠，也能防止重复执行事件。
- 从库只读要锁死：设置read_only=ON，并禁止SUPER权限用户在从库写入，否则主从数据会悄然漂移，灾备失效。
- 监控不可少：重点盯Seconds_Behind_Master（注意它在IO线程异常时可能为0）、Slave_SQL_Running_State状态、以及复制错误码（如1062主键冲突、2013连接中断）。
自动切换的风险与人工切换的底线逻辑
自动切换听起来高效，但多数线上事故源于“切得太快、验得不够”。真正可靠的切换，必须满足三个前提：
- 主库确认宕机：不能仅凭心跳超时就切，要结合OS进程、端口、日志写入能力综合判断，避免脑裂。
- 最新事务已同步到备库：检查备库是否已应用完所有GTID，或比对主库SHOW MASTER STATUS与备库SHOW SLAVE STATUS中的Executed_Gtid_Set。
- 应用连接已重定向且验证通过：切换后立即用最小业务SQL（如SELECT COUNT(*) FROM health_check_table）验证新主库可读可写，并确保中间件或DNS完成流量切换。
建议初期禁用全自动切换，采用“监控告警 + 脚本辅助 + 人工确认”的半自动流程，成熟后再逐步放开。
切换后的必做动作清单
切完不等于结束，遗漏后续动作会导致二次故障：
- 重置原主库角色：原主库恢复后不要直接拉起为新主，应先停掉MySQL，清空auto.cnf和relay log，再以从库身份重新接入新主同步。
- 校验数据一致性：用pt-table-checksum快速扫描关键表，发现差异立即用pt-table-sync修复，别等业务报错才处理。
- 更新元信息：修改高可用管理平台、配置中心、连接池配置中的主库地址，同步通知DBA、开发、SRE团队，避免有人直连旧IP继续写入。
- 回溯日志分析根因：查主库error log、系统dmesg、磁盘IO等待、网络抖动记录，明确是硬件故障、误操作还是SQL风暴导致宕机，针对性加固。
绕不开的现实问题：大表DDL与复制延迟
主备环境下，ALTER TABLE这类操作极易引发长时间复制延迟甚至中断：
- 避免在主库直接执行耗时DDL，改用pt-online-schema-change或gh-ost工具，在从库先建影子表，再原子切换，主库压力小、复制链路稳。
- 如果必须用原生DDL，务必在低峰期操作，并提前在从库执行STOP SLAVE，待主库执行完再手动START SLAVE，避免主从同时锁表卡死。
- 定期清理没用的索引和冗余字段，减少每条DML产生的binlog体积，从源头压降复制带宽压力。
灾备不是一劳永逸的开关，而是持续验证的习惯。每月至少一次模拟主库宕机、走通切换全流程，比任何文档都管用。
