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

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

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

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

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

## 先定义什么叫"正常"

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

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

| 指标 | 看什么 | 采集方式 |
| --- | --- | --- |
| 错误率 | 业务接口的失败占比 | 应用监控 |
| P99 延迟 | 尾部请求的耗时 | 应用监控 |
| 复制延迟 | 主从之间的位点差 | 心跳表或监控项 |
| 可写状态 | 当前主库能不能写 | 定期试写 |
| 数据一致性 | 主从关键表的行数与校验和 | 对账脚本 |

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

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

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

## 注入点清单

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

| 注入点 | 手法 | 验证什么 |
| --- | --- | --- |
| 进程崩溃 | kill -9 数据库进程 | 编排层能不能在秒级发现并拉起 |
| 主库只读 | 打开 super_read_only | 写入失败会不会被业务感知并正确反馈 |
| 复制中断 | 停掉从库回放线程 | 复制延迟告警会不会触发 |
| 网络分区 | 屏蔽对端数据库端口 | 脑裂防护有没有生效 |
| 磁盘抖动 | 限制 IO 带宽或加延迟 | 慢查询和连接堆积的扩散速度 |
| 连接打满 | 开满连接数 | 应用侧的超时与重试策略 |
| 时钟漂移 | 人为偏移系统时间 | 依赖时钟的判定逻辑会不会出错 |

几种常用的注入手法：

```bash
# 注入点一：数据库进程直接崩掉
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 秒，切换后关键表对账不一致。任何一条命中就中止，不犹豫。

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

## 数据安全的三条底线

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

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

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

| 时刻 | 动作 | 关注点 |
| --- | --- | --- |
| T-3 天 | 冻结变更，确认备份可恢复，通知业务方 | 变更窗口 |
| T-30 分钟 | 采集稳态基线 | 基线快照 |
| T-5 分钟 | 确认回退通道、中止权归属 | 人员到位 |
| T-0 | 注入：主库进程 kill -9 | 告警是否触发、多久触发 |
| T+40 秒 | 检测完成，编排层发现主库不可用 | 检测耗时 |
| T+2 分钟 | 触发切换：VIP 漂移、连接串切换 | 切换开始时间 |
| T+4 分钟 | 验证新主可写，应用侧连接重建 | 应用恢复时间 |
| T+22 分钟 | 关键表对账：行数、校验和 | 数据差异 |
| T+30 分钟 | 业务指标回到基线范围 | 实际 RTO |
| T+45 分钟 | 复盘，逐段核对耗时 | 问题清单 |

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

| RTO 组成 | 方案里估的 | 实际测的 | 差在哪 |
| --- | --- | --- | --- |
| 检测 | 15 秒 | 40 秒 | 告警阈值设得太宽 |
| 决策 | 未计 | 12 分钟 | 没人被明确授权喊切 |
| 执行 | 30 秒 | 90 秒 | 脚本里有写死的 IP |
| 应用恢复 | 未计 | 18 分钟 | 连接池没配自动重建 |
| 数据校验 | 未计 | 8 分钟 | 校验脚本要手工跑 |

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

## 避坑清单

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

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

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

## 写在最后

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

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

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

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


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

数据库故障演练：方案写30秒，真跑要40分钟

从一次真实断电切入，方案写30秒切换、实际花了40分钟。把 RTO 拆成检测、决策、执行、应用恢复、数据校验五段，给出稳态指标、七类注入点与命令、爆炸半径分级、中止条件与时间线复盘。

数据库

测试

职业发展

高可用方案必须经演练验证，否则纸面30秒RTO只是执行段。演练需先定义稳态基线，按爆炸半径逐级注入故障，并明确中止条件。备份需真实恢复验证，RTO应分段测量，问题闭环管理。真正的高可用靠演练，不是架构图。

数据一致性

数据安全

数据中心

代码解释

灾备

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据库故障演练：方案写30秒，真跑要40分钟-腾讯云开发者社区-腾讯云

数据库故障演练：方案写30秒，真跑要40分钟

数据库故障演练：方案写30秒，真跑要40分钟

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐