方案写30秒，真断电花了40分钟｜我把切换耗时拆成了五段

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

前年我跟过一次真实的断电。系统是两个数据中心加一个异地灾备。方案评审我参与了，里面写的切换时间是 30 秒。每一步都写了，脚本也提前写好，平时跑得也稳。说实话，我当时觉得定期演练有点多余。

那天真断电了，从主中心挂掉到业务恢复，我们花了 40 分钟。

事后复盘，我把这 40 分钟拆开看。真正执行切换的那一段，只用了 90 秒。有 12 分钟，是两边的人在确认"到底是不是真的要切"。还有将近 20 分钟，耗在应用那边的连接重建和数据对账上。方案里写的 30 秒，只算了执行这一段。

那次之后我改了个习惯。任何一套高可用方案，我都要求它在演练里跑一遍。跑不过的方案，写得再漂亮我也不敢签字。以前做设计的时候我们有个词叫走查。设计稿画得再好，也得有人拿着它逐屏点一遍才算验收。数据库的高可用也一样，方案写得再全，也得跑一遍才知道行不行。

先定义什么叫"正常"

演练最容易漏掉的一步，是事先定义稳态。稳态就是一组能说清楚的指标。它们落在设定范围内，就说明系统正常。没有这个判据，演练做完你也不知道过没过。更糟的是，你可能压根没发现演练把系统弄坏了。

指标要从业务层选，不能只看数据库层。数据库各项都平稳，业务可能已经是坏的。举个我遇到过的情形。主库被切成只读之后，数据库进程好好的，连接数正常，复制也没断。但所有写入都失败了。只看数据库指标，这次演练的结论会是"没有影响"。我一般盯这几个。

稳态基线要在注入前采一次，恢复后再采一次，逐项对比。

复制延迟这项要单独说。它是演练里最容易骗人的指标。Seconds_Behind_Master 这类字段有个坑。从库回放线程一停，它就显示成 NULL，看着像没有延迟。我更信心跳表。主库定时写一个时间戳，从库读出来算差值，这个数骗不了人。

-- 复制延迟：主库定时写心跳，从库读时间差
SELECT
  TIMESTAMPDIFF(SECOND, ts, NOW()) AS repl_lag_seconds
FROM heartbeat_log
ORDER BY ts DESC
LIMIT 1;

注入点清单

演练的核心动作是注入故障。故障不是随便制造的，每一种注入都对应一个要验证的能力。

几种常用的注入手法：

# 注入点一：数据库进程直接崩掉
kill -9 $(cat /var/lib/mysql/mysqld.pid)

# 注入点二：主库置为只读，模拟存储故障后的保护状态
mysql -e "SET GLOBAL super_read_only = ON;"

# 注入点三：掐断本机与对端的数据库端口，模拟网络分区
iptables -A INPUT  -p tcp --dport 3306 -j DROP
iptables -A OUTPUT -p tcp --sport 3306 -j DROP

网络分区这一项要多留个心。它验证的是脑裂防护。两个中心互相看不到。如果两边都认为自己该当主，数据就分叉了。演练时先把仲裁或投票机制的原理搞清楚，再动手。

爆炸半径一级一级放大

这是我最看重的一条纪律。演练的破坏力必须可控。方法是一级一级放大，上一级通过才允许进下一级。

第一次演练绝不能在生产的核心主库上做。这句话我说过很多次，还是见过有人直接在主库上试 kill -9。他的理由是"我们有从库，切过去就行"。结果那套切换脚本从没在真实场景跑过。脚本里一个写死的 IP 没改，切换直接卡住。

剧本里必须先写中止条件

演练脚本不能只写"做什么"，还要写"什么时候停"。要提前定三件事。哪几个指标一破就立刻回滚。谁有权喊停。喊停之后多久能回到稳态。这三个问题在演练开始前就要有明确答案，不能现场商量。

阈值我给个参考。错误率超过基线的两倍，P99 超过基线的三倍，复制延迟超过 30 秒，切换后关键表对账不一致。任何一条命中就中止，不犹豫。

喊停权要落到一个人头上，不能是"大家一起判断"。演练现场最怕的局面，是所有人都觉得该停，但没人开口。

数据安全的三条底线

演练前必须确认三件事。备份是真的能恢复的，不是备份任务显示成功。回退通道是通的，回退动作有人验过。演练产生的数据能回收，不会混进生产。第一件我要专门强调。备份任务的"成功"只代表文件写出来了。能不能恢复出来，是另一回事。我现在的做法是，演练开始前先在一个隔离环境里做一次真实恢复。恢复不出来的备份，等于没有备份。

一次完整的切换演练时间线

下面这张表是一场完整演练的时间线，从准备到恢复稳态。这是我每次评审都会拿出来看的东西。

这张表最有用的地方，是把 RTO 拆成了几段。检测一段，决策一段，执行一段，应用恢复一段，数据校验一段。方案里写的那个数字，通常只覆盖执行那一段。

差距的来源基本都在这里。方案里那个 30 秒没有错，它只是定义得比业务感知到的范围窄。

避坑清单

别在生产主库上做第一次演练。爆炸半径永远从最小的那一级开始，一级一级放大。上一级的剧本没跑通，就不许进下一级。

演练脚本要和变更一起做版本管理。不然半年后有人问起来，当时注入了什么、跑了哪些步骤，没人答得上来。脚本进了版本库，演练才有可复现性。

最后一条是我自己搞错的。我有一次演练报告写得挺漂亮，问题清单列了七条。然后就没有然后了。半年后另一次演练，前三条问题原封不动又出现了一遍。那次我才意识到，演练报告不进变更流程，就是一张废纸。现在我的做法是，演练发现的问题当天就建任务，指定负责人和期限。下次演练先复核上一批问题的闭环情况。

写在最后

高可用不是架构图画出来的，是演练出来的。一份没有发现任何问题的演练报告，本身就是最大的问题信号。系统是活的，配置会漂，脚本会旧，人也会换。每次都演练出"一切正常"，只说明两件事，要么没注入到点上，要么判据设得太松。

我现在判断一套高可用方案靠不靠谱，不看架构图上有几个圈。我看它有没有一份带时间线的演练记录。有记录的，说明被真实检验过。没有的，说明还停在纸上。

你们的高可用演练，最近一次是什么时候做的？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋