数据库主从架构下，主库承担写入压力，从库负责分担读流量或作为容灾备份。当主库出现硬件故障、网络分区或计划内维护时，必须执行主从切换。切换动作看似只是把写入指向新的主库，但涉及复制状态校验、流量摘除、角色提升和连接池刷新等多个环节，任何一个步骤处理不当，都可能导致请求超时、数据不一致甚至双主冲突。本文从切换流程、性能风险和一致性保障三个维度展开，帮助读者理解切换背后的技术细节。
一、主从切换的标准流程拆解
主从切换可以分为计划内切换和故障切换。计划内切换通常由运维主动发起，在低峰期进行，有充足时间做前置检查；故障切换则往往由高可用组件自动触发，时间窗口在秒级到分钟级，需要依赖外部仲裁。两者的目标一致，但故障切换对流程的自动化和幂等性要求更高。
在标准切换流程中，首先需要从所有从库中挑选一个数据最新的节点作为候选主库。可以通过比较SHOW SLAVE STATUS中的Seconds_Behind_Master和Retrieved_Gtid_Set等指标判断延迟情况。选定后，要在从库上执行STOP SLAVE停止复制，确保不再接收旧主库的binlog事件。接着必须校验该从库是否已经应用完所有已接收的日志，避免提升后出现数据丢失。
随后将应用连接池或数据库代理中的写流量摘除，指向新主库。这一步如果依赖DNS或VIP，需要考虑缓存生效时间。旧主库如果仍然存活，应该将其设置为只读或直接关闭写入，防止脑裂。最后还需要把其他从库重新指向新主库，并更新监控与备份配置。下面是查看复制状态的核心命令，切换前需要反复确认延迟趋近于零。
-- 查看从库复制状态 SHOW SLAVE STATUS\G -- 关键字段：Seconds_Behind_Master, Retrieved_Gtid_Set, Executed_Gtid_Set
二、切换过程中的性能风险来源
切换期间最典型的性能风险是复制延迟未收敛时提升从库，导致刚写入旧主库的数据在从库上不存在，业务读到旧值或写入冲突。这种延迟可能来自网络抖动、大事务或者从库SQL线程单线程回放瓶颈。在计划内切换中，可以通过观察延迟曲线，等待Seconds_Behind_Master归零后再操作；但在故障切换中，主库已经不可用，延迟数据无法获取，只能依赖半同步复制或GTID集合比对来估算丢失窗口。
第二个风险是半同步复制超时带来的主库写性能抖动。为了增强一致性，很多集群启用了半同步复制，要求从库确认收到binlog后才返回提交成功。一旦从库网络变慢或磁盘IO升高，主库事务提交会被阻塞，直到超时时间到达并降级为异步复制。如果超时设置不合理，比如设置为10秒，那么切换前几分钟内主库的写入吞吐可能出现毛刺甚至雪崩。因此切换前需要评估rpl_semi_sync_master_timeout参数，并在从库健康时保持半同步，避免切换瞬间才开启。
另外，连接池与客户端缓存也会放大切换影响。许多Java应用使用HikariCP或Druid连接池，池中物理连接在切换后仍然指向旧主库的IP地址，如果代理层没有统一刷新，新的写请求会打到已经只读的旧主库上，报错或者写入失败。同样，DNS解析结果如果被JVM缓存，VIP漂移后可能几十秒内无法生效。可以通过设置较短的DNS TTL和连接池的maxLifetime来降低这类延迟。
从库提升为新主库后，其Buffer Pool和查询缓存通常是冷状态，原先大量命中旧主库内存的查询会回源到磁盘，导致新主库瞬间压力增大。尤其是当业务读流量也同时切到新主库时，新主库可能因为冷缓存和突发写流量叠加而出现性能拐点。可以提前对新主库进行预热，或分阶段切换读流量。以下是一个半同步插件配置示例。
# 主库安装半同步插件 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; SET GLOBAL rpl_semi_sync_master_enabled = 1; SET GLOBAL rpl_semi_sync_master_timeout = 1000; # 从库安装半同步插件 INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; SET GLOBAL rpl_semi_sync_slave_enabled = 1;
三、一致性保障机制与实践
数据一致性是主从切换中最需要优先保障的目标。传统基于binlog位置的复制只能记录偏移量，切换后需要人工计算新主库对应位置，容易出错。MySQL 5.6之后引入的GTID全局事务标识为每个事务生成唯一编号，格式为server_uuid:transaction_id，从库可以通过对比Executed_Gtid_Set快速判断数据差距。启用GTID后，切换时无需手动指定binlog文件和偏移量，直接执行CHANGE MASTER TO MASTER_AUTO_POSITION=1即可自动对齐。
-- 确认GTID状态 SELECT @@gtid_mode, @@enforce_gtid_consistency; -- 查看已执行事务集合 SHOW MASTER STATUS; SHOW SLAVE STATUS\G
除了GTID，半同步复制是防止数据丢失的关键。默认异步复制下，主库提交后立即返回，从库可能落后数秒甚至数十秒，主库宕机后这些未同步的事务会永久丢失。半同步复制要求至少一个从库确认收到binlog后，主库才返回成功，将丢失窗口缩小到网络往返级别。但要区分普通半同步和增强半同步：普通半同步在提交后等待从库ACK，增强半同步在提交前等待，可以确保主库崩溃时不会出现已提交但未同步的事务。
切换前还必须做数据对账。可以使用pt-table-checksum工具在主库生成校验和，从库执行比较，发现不一致的表后通过pt-table-sync修复。对于核心业务表，可以在低峰期加只读锁做快照对比，确保切换后业务读取到的数据与切换前主库完全一致。此外，建议在切换流程中加入校验步骤，例如比较主从库各表的行数和最大自增ID，以及最近N分钟写入量是否匹配。
四、切换后监控与回退策略
切换完成并不代表风险结束，新主库是否稳定需要持续监控。重点指标包括延迟类指标如Seconds_Behind_Master是否保持在0，新主库的Threads_running、Innodb_row_lock_waits等并发等待指标是否异常升高，以及应用层请求错误率和P99延迟。如果出现写入性能急剧下降或复制延迟无法收敛，需要快速触发回退。
回退策略必须在切换前制定，并明确回退条件。例如新主库在切换后5分钟内出现持续锁等待、CPU利用率超过阈值、或者业务事务失败率超过1%时，立即停止新主库写入，将流量切回旧主库。如果旧主库已经停机无法恢复，则需要从其他从库重新选主。回退操作同样涉及数据一致性校验，必须确保新主库上已经产生的事务能够回放回旧主库或不会造成双主冲突。
为了避免切换后出现脑裂，建议在应用层或代理层增加全局写锁，例如使用ZooKeeper或etcd存放当前主库标识，所有写请求先获取锁确认目标节点。同时，将旧主库在切换后强制设置为read_only=1，即使网络恢复也不会自动接受写入。监控系统还应记录每次切换的事件日志，包括切换原因、耗时、候选主库延迟情况等，以便事后复盘和优化。