主库故障演练的核心在于从业务RTO出发，通过模拟真实故障并记录从库提升的时间线，从而验证从库能否在预设的切换窗口内完成自动或手动提升，确保高可用架构的可靠性。
故障演练前：从库切换的预期时间怎么定
在动手演练之前,首先要明确“预期时间”这个基准，如果没有这个标准，演练结果就无从对比，预期时间怎么定，不是拍脑袋决定的，而是基于业务容忍度、复制延迟基线以及检测切换机制的综合评估。
切换时间的主要影响因素
- 从库复制延迟：这是最直接的因素，如果从库落后主库数秒甚至数分钟，切换时这些未同步的数据会丢失或导致回滚，切换时间必然被拉长，常见延迟来源包括大事务、慢查询、从库硬件性能不足。
- 故障检测机制：主库心跳超时配置决定了从库何时认定主库不可用，超时值设置过长（如30秒），检测时间就会占掉切换时间的大部分；设置过短（如1秒）又容易因网络抖动造成误切换，需要根据网络稳定性权衡。
- 切换流程的自动化程度：使用MHA、Orchestrator或自研的一键切换脚本，能在几秒内完成选举和提升；而手动切换则涉及登录、检查、执行命令，耗时通常在分钟级，自动化工具虽然增加成本，但能大幅缩短切换时间。
如何设定合理的预期时间窗口
- 业务RTO要求：行业共识认为，预期切换时间应控制在业务可接受的窗口内，例如在线交易系统通常要求RTO在30秒以内，而内部系统可放宽到5分钟，需要根据业务连续性文档来定。
- 从库硬件与网络环境：相同配置的从库在不同地域（如异地机房）之间，因网络延迟会导致复制延迟偏高，切换时间也会相应不同，演练前需记录常态下的延迟基线。
- 历史复制延迟基线：通过监控工具（如pt-heartbeat）连续采集一周的高峰与低谷延迟数据，取95分位值作为延迟上限，将该值加上检测超时时间，再预留20%的缓冲，即为合理的预期切换时间。
分步验证：从库切换时间是否达标
有了预期时间后,就可以进入验证环节，验证从库切换时间是否达标，核心在于精确记录关键节点的时间戳，并与预期窗口进行对比。
建立监控与基准
- 启用pt-heartbeat在数据库上持续写入心跳表，从库通过读取心跳时间差来计算复制延迟，建议采样间隔设为1秒，以便精确捕捉延迟波动。
- 设置监控指标：包括故障注入时间、从库检测到主库不可用时间、从库提升为新的主库时间、应用层重新连接成功时间，可以使用系统时间戳（如
date +%s%N）记录每一步的精确时间。
模拟主库故障的常用方法
- 停止MySQL服务：
systemctl stop mysql或kill -9进程，模拟进程崩溃，这是最直接的方式，但不会触发OS层面的网络异常。 - 切断网络连接：通过iptables或云平台的安全组规则阻断主库的3306端口，
iptables -A INPUT -p tcp --dport 3306 -j DROP，这种方式更接近真实网络分区场景。 - 模拟磁盘故障：在写满磁盘或卸载挂载点，使主库无法写入数据，触发复制异常，需要提前规划好恢复步骤，避免影响演练环境。
记录切换时间的关键节点
- 节点1：故障注入时间（T0）
- 节点2：从库检测到主库不可用时间（T1，通常从库连续N次心跳超时后标记）
- 节点3：从库提升为新的主库时间（T2，选举完成并执行
stop slave; reset slave;等操作） - 节点4：业务应用重新连接并成功执行写操作时间（T3，通过连接池重试机制确认）
将T3-T0作为总切换时间，T1-T0作为检测时间，T2-T1作为提升时间，T3-T2作为应用重连时间，每个环节超过预期值，都需要单独分析。
对比预期窗口评估结果
- 如果总切换时间超过预期窗口,首先检查延迟是否在基线范围内，如果演练时延迟远高于基线，说明演练负载或环境与日常差异较大，需要调整条件后重试。
- 如果检测时间过长,应检查心跳超时配置是否合理，以及从库的监控线程是否被阻塞。
- 如果提升时间过长,可能源于从库数据量巨大或同步点未对齐，需要优化切换脚本或调整参数。
模拟真实场景：主库故障演练实操步骤
理论验证之后,需要动手执行，确保每一步都可重复、可验证，以下步骤以MySQL主从架构为例，无论使用云数据库还是自建环境，逻辑相似。
使用自动化切换工具（如MHA/Orchestrator）
- 配置要点：在MHA的
app.cnf中设置master_ip_failover脚本，并确保所有节点的ssh互通，Orchestrator则需配置DetectClusterAlias和RecoveryPeriodBlockSeconds。 - 演练触发命令：对于MHA，执行
masterha_master_switch --conf=app.cnf --master_state=dead进行模拟故障切换，Orchestrator可以通过API或orchestrator-client -c force-master-failover -a <alias>触发。 - 验证输出：工具会输出每一步的日志，重点关注“Master failover start”到“All slaves started”之间的时间差，以及是否有任何错误提示。
手动演练步骤（以MySQL为例）
- 步骤1：在从库上执行
SHOW SLAVE STATUSG确认复制正常，记录Seconds_Behind_Master。 - 步骤2：模拟主库故障，例如
systemctl stop mysql。 - 步骤3：在从库上执行
SHOW SLAVE STATUSG，观察Slave_SQL_Running和Slave_IO_Running是否变为No，且Last_IO_Error提示连接错误。 - 步骤4：执行
STOP SLAVE; RESET SLAVE ALL;清空从库复制状态。 -
步骤5：执行
CHANGE MASTER TO MASTER_HOST=''清空主库信息（可选）。 - 步骤6：执行
SHOW VARIABLES LIKE 'read_only';确认从库是否为只读，然后执行SET GLOBAL read_only=OFF;允许写操作。 - 步骤7：更新应用配置或DNS，将写请求指向新主库。
- 步骤8：在应用层执行一个测试写入，确认成功。
验证应用层切换时间
- 应用层通常使用连接池（如HikariCP、Druid），需要配置
connectionTimeout和maxLifetime，以便在旧连接断开后快速建立新连接，演练时观察应用日志中从抛出异常到成功获取连接的时间差。 - 如果应用层重试次数过多或超时过长,会导致用户感受到中断，建议在演练前将连接池的心跳检测间隔设为较短（如5秒），并启用
testOnBorrow。
Q&A：主库故障演练验证从库切换常见问题
主库故障时从库切换时间一般多久？如何与预期对比？
切换时间通常在10秒到2分钟之间，具体取决于复制延迟、检测超时和切换工具效率，演练时记录T0到T3的时间，与预定的RTO进行对比，如果超出，则排查延迟或检测配置，并调整预期时间窗口。
演练时是否要模拟高并发负载？
是的，否则切换时间可能被低估，主库在高负载下的故障会导致从库复制延迟增大，提升过程中也可能出现数据一致性检查耗时增加，建议在峰值压力时段进行演练，或使用压测工具模拟50%左右的业务流量。
切换演练过程中业务中断如何处理？
提前规划演练窗口，优先在灰度环境或只读业务上执行，如果必须影响主业务，应确保有回滚预案，例如保留旧主库的binlog，以便在切换失败时快速恢复，演练完成后，还需验证数据一致性，确保没有丢失事务。
通过定期演练并量化切换时间,团队能在真出故障时从容应对，确保高可用承诺落地。