大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
10 月 19 日凌晨两点四十四分，昆明公积金发了一条通告。存储系统集群节点故障，数据库运行异常。线下柜面和线上渠道，全部暂停。10 月 22 日，恢复时间定了。23 日 9 点柜面恢复，24 日零点线上恢复。从 19 日凌晨算起，柜面停了 102 小时，线上停了 117 小时。
缴存、提取、贷款、查询、结算，都压在同一套核心库上。底下坏了，上面全停。我看到这条新闻，第一反应不是「怎么又崩了」。我想的是：一个节点故障，怎么能拖这么久？
通告里的两句话，有先后
「存储系统集群节点故障」，「数据库运行异常」。这两句不是并列关系。按字面读，存储先出问题，数据库跟着异常。这个链条我熟。数据库跑在存储上，存储一抖，IO 就卡。查询等不到返回，连接越堆越多，应用开始超时。用户看到的是系统打不开，运维看到的是数据库没响应。真正坏的地方，可能在更下面。
但集群节点故障，不该等于全中心停摆。集群这个词，本来就是为坏一个不影响整体准备的。如果坏一个节点就全停，无非几种可能。切换没生效。集群没覆盖到真正的故障点。或者存储本身还是单点。我不确定昆明这次卡在哪一步，官方没说细节。但从 19 日发通告，到 22 日才确定恢复时间，中间隔了三天多。这三天里，难的恐怕不是切换本身。切过去之后，还得确认业务真的能开。能切，和敢开，差的就是这一步。
停摆 102 小时，暴露的是两层问题
一层是高可用。出事那一刻，有没有另一份数据顶上？切换要多久？另一层是恢复流程。切不过去怎么办？备件在哪？厂商多久到？数据怎么校验，业务怎么对账？
这两层常被混在一起。买了一套集群，就以为高可用有了。真出事才发现，切换脚本没人跑过。备节点起不来。或者起来了，数据落后一大截。公积金业务是连着的。还款划扣停了。官方说恢复后统一补扣，不记逾期，不影响征信。这个兜底没问题。但它也说明，停摆不是某个功能不能用。是一整条业务链暂停。对外看，柜面停了 102 小时，线上 117 小时。对内，可能是反复定位、尝试、验证，直到敢开。
换数据库，别把故障链一起搬走
这两年信创替代推得快，公积金系统也在换国产库。方向没问题。我担心的是另一种做法。原来用什么库，现在找个国产库一对一换上。服务器还是那批，存储还是那套集中式存储，拓扑也没动。
库换了，故障域没换。
原来存储是单点，换完还是单点。原来靠人工切，换完还是人工。这种情况下，数据库本身再稳，也挡不住存储层出事。迁移是个难得的窗口。平时不敢动的架构，这时候有机会一起改。要是只换库、不动架构，等于把老问题原样搬进新系统。
我会怎么验收一套容灾
不看方案写得多厚，看几个问题能不能当场答上来。先画故障域。机房、机柜、存储节点、数据库节点、网络，一个个标出来。问一句：这里坏了，哪些业务会停？
| 出问题的位置 | 应该是什么结果 | 我要追问的 |
|---|---|---|
| 单台数据库节点 | 自动切换，业务基本无感 | 切换几秒？连接会自动重连吗？ |
| 存储节点或存储集群 | 数据库不受影响 | 数据库还依赖共享存储吗？ |
| 单个机柜 | 可降级，不中断 | 副本跨机柜了吗？ |
| 单个机房 | 能切到异地 | 异地副本是同步还是异步？ |
然后问切换。自动还是人工。谁有权按按钮。凌晨三点能不能找到人。再问数据。RTO 是恢复要多久，RPO 是能丢多少。这两个数不是方案里写多少就是多少，是演练出来的。同一个系统，主库断电和机房断电，结果可能差很远。最后问回切。很多人只演「切过去」，不演「切回来」。旧主库的增量怎么补，双写怎么停，业务什么时候回原中心。这些不写清楚，切换只完成一半。
我做过一张演练记录表，比架构图有用。
| 演练项 | 合格线 | 要记录什么 |
|---|---|---|
| 主库直接断电 | 自动切换，业务可恢复 | 实际耗时、失败原因 |
| 存储节点离线 | 业务不中断 | 数据库是否有感知 |
| 机房级故障 | 切到异地，数据不丢 | RPO 实际值、校验结果 |
| 回切 | 数据一致，业务回归 | 回切耗时、补数据方式 |
表格空着不可怕。可怕的是从来没填过。
我以前把「有备库」当成「有容灾」
刚入行那会儿，看到一套系统有主库有备库，我就觉得稳了。后来一次主机故障，备库起来了，应用连不上。连接串还指着旧地址，防火墙也没放行。还有一次，备库延迟太大。切过去丢了一段数据，业务对不上账。从那以后我改了个习惯。看容灾方案，我先问一句。上次真演练是什么时候，报告能给我看吗。
国产库这边，我也用同一套标准看。金仓 KES 的读写分离集群，是一主多备、多副本。配合集群组件，可以做自动切换。这类能力听上去都差不多，差别在落地。上线前把切换、回切、数据校验各跑一遍。这比画十页架构图管用。
同样的问题，怎么避免再来一次
第一，把故障域画出来，贴在值班室。不用漂亮，能看懂「哪里坏了影响谁」就行。
第二，安排一次真演练。别挑低峰期手动切一下就算。直接断主库、断存储、断机房，看系统自己怎么反应。演练时把业务方拉进来，别自己演给自己看。
第三，把恢复流程写成清单。谁通知，谁决策，先验什么，后开什么，数据对不上找谁。这 102 小时里最耗时间的，往往不是技术动作。是等人拍板。
避坑清单
别把「有集群」当成「有容灾」。集群解决节点冗余。容灾还要看故障域、切换方式、数据副本。少一个，关键时刻都可能掉链子。验收别只测正常切换。主库直接断电、存储不可用、机房失联。这些场景难看，但更接近真实故障。越难看，越要练。
最后一条是我自己踩的。有次演练切过去很顺。回切时才发现，旧主库的增量没补回来。业务多跑了一天双写。现在我把回切写进脚本。切过去不算完，切回来、数据对上，才算完。
写在最后
昆明这次，业务已经恢复。具体原因还没公布，我不猜。但有一件事值得记住。停摆的 100 多个小时里，有人在等提取公积金交房租。有人在等办贷款。他们不关心底层是存储坏了，还是数据库坏了。他们只关心一件事：什么时候能办。
这就是民生系统和普通业务的区别。普通系统挂了，大不了明天再用。公积金停了，可能影响一个家庭的现金流。所以容灾这件事，平时看着像技术指标。真到那一刻，它是一句承诺。系统坏了能顶上，数据不会丢。
方案里写 RTO 几秒，不如演练场上真断一次电。架构图画得再漂亮，不如值班的人知道第一步该干什么。系统会坏，这不稀奇。坏了之后多久能起来，才是一个团队真正的水平。我们这行做久了，容易把「高可用」当成一个参数。其实它最后落到一件很具体的事。别人最需要你的时候，你在线。
你们单位的容灾，上一次真演练是什么时候？评论区聊聊。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
10 月 19 日凌晨两点四十四分，昆明公积金发了一条通告。存储系统集群节点故障，数据库运行异常。线下柜面和线上渠道，全部暂停。10 月 22 日，恢复时间定了。23 日 9 点柜面恢复，24 日零点线上恢复。从 19 日凌晨算起，柜面停了 102 小时，线上停了 117 小时。
缴存、提取、贷款、查询、结算，都压在同一套核心库上。底下坏了，上面全停。我看到这条新闻，第一反应不是「怎么又崩了」。我想的是：一个节点故障，怎么能拖这么久？
通告里的两句话，有先后
「存储系统集群节点故障」，「数据库运行异常」。这两句不是并列关系。按字面读，存储先出问题，数据库跟着异常。这个链条我熟。数据库跑在存储上，存储一抖，IO 就卡。查询等不到返回，连接越堆越多，应用开始超时。用户看到的是系统打不开，运维看到的是数据库没响应。真正坏的地方，可能在更下面。
但集群节点故障，不该等于全中心停摆。集群这个词，本来就是为坏一个不影响整体准备的。如果坏一个节点就全停，无非几种可能。切换没生效。集群没覆盖到真正的故障点。或者存储本身还是单点。我不确定昆明这次卡在哪一步，官方没说细节。但从 19 日发通告，到 22 日才确定恢复时间，中间隔了三天多。这三天里，难的恐怕不是切换本身。切过去之后，还得确认业务真的能开。能切，和敢开，差的就是这一步。
停摆 102 小时，暴露的是两层问题
一层是高可用。出事那一刻，有没有另一份数据顶上？切换要多久？另一层是恢复流程。切不过去怎么办？备件在哪？厂商多久到？数据怎么校验，业务怎么对账？
这两层常被混在一起。买了一套集群，就以为高可用有了。真出事才发现，切换脚本没人跑过。备节点起不来。或者起来了，数据落后一大截。公积金业务是连着的。还款划扣停了。官方说恢复后统一补扣，不记逾期，不影响征信。这个兜底没问题。但它也说明，停摆不是某个功能不能用。是一整条业务链暂停。对外看，柜面停了 102 小时，线上 117 小时。对内，可能是反复定位、尝试、验证，直到敢开。
换数据库，别把故障链一起搬走
这两年信创替代推得快，公积金系统也在换国产库。方向没问题。我担心的是另一种做法。原来用什么库，现在找个国产库一对一换上。服务器还是那批，存储还是那套集中式存储，拓扑也没动。
库换了，故障域没换。
原来存储是单点，换完还是单点。原来靠人工切，换完还是人工。这种情况下，数据库本身再稳，也挡不住存储层出事。迁移是个难得的窗口。平时不敢动的架构，这时候有机会一起改。要是只换库、不动架构，等于把老问题原样搬进新系统。
我会怎么验收一套容灾
不看方案写得多厚，看几个问题能不能当场答上来。先画故障域。机房、机柜、存储节点、数据库节点、网络，一个个标出来。问一句：这里坏了，哪些业务会停？
| 出问题的位置 | 应该是什么结果 | 我要追问的 |
|---|---|---|
| 单台数据库节点 | 自动切换，业务基本无感 | 切换几秒？连接会自动重连吗？ |
| 存储节点或存储集群 | 数据库不受影响 | 数据库还依赖共享存储吗？ |
| 单个机柜 | 可降级，不中断 | 副本跨机柜了吗？ |
| 单个机房 | 能切到异地 | 异地副本是同步还是异步？ |
然后问切换。自动还是人工。谁有权按按钮。凌晨三点能不能找到人。再问数据。RTO 是恢复要多久，RPO 是能丢多少。这两个数不是方案里写多少就是多少，是演练出来的。同一个系统，主库断电和机房断电，结果可能差很远。最后问回切。很多人只演「切过去」，不演「切回来」。旧主库的增量怎么补，双写怎么停，业务什么时候回原中心。这些不写清楚，切换只完成一半。
我做过一张演练记录表，比架构图有用。
| 演练项 | 合格线 | 要记录什么 |
|---|---|---|
| 主库直接断电 | 自动切换，业务可恢复 | 实际耗时、失败原因 |
| 存储节点离线 | 业务不中断 | 数据库是否有感知 |
| 机房级故障 | 切到异地，数据不丢 | RPO 实际值、校验结果 |
| 回切 | 数据一致，业务回归 | 回切耗时、补数据方式 |
表格空着不可怕。可怕的是从来没填过。
我以前把「有备库」当成「有容灾」
刚入行那会儿，看到一套系统有主库有备库，我就觉得稳了。后来一次主机故障，备库起来了，应用连不上。连接串还指着旧地址，防火墙也没放行。还有一次，备库延迟太大。切过去丢了一段数据，业务对不上账。从那以后我改了个习惯。看容灾方案，我先问一句。上次真演练是什么时候，报告能给我看吗。
国产库这边，我也用同一套标准看。金仓 KES 的读写分离集群，是一主多备、多副本。配合集群组件，可以做自动切换。这类能力听上去都差不多，差别在落地。上线前把切换、回切、数据校验各跑一遍。这比画十页架构图管用。
同样的问题，怎么避免再来一次
第一，把故障域画出来，贴在值班室。不用漂亮，能看懂「哪里坏了影响谁」就行。
第二，安排一次真演练。别挑低峰期手动切一下就算。直接断主库、断存储、断机房，看系统自己怎么反应。演练时把业务方拉进来，别自己演给自己看。
第三，把恢复流程写成清单。谁通知，谁决策，先验什么，后开什么，数据对不上找谁。这 102 小时里最耗时间的，往往不是技术动作。是等人拍板。
避坑清单
别把「有集群」当成「有容灾」。集群解决节点冗余。容灾还要看故障域、切换方式、数据副本。少一个，关键时刻都可能掉链子。验收别只测正常切换。主库直接断电、存储不可用、机房失联。这些场景难看，但更接近真实故障。越难看，越要练。
最后一条是我自己踩的。有次演练切过去很顺。回切时才发现，旧主库的增量没补回来。业务多跑了一天双写。现在我把回切写进脚本。切过去不算完，切回来、数据对上，才算完。
写在最后
昆明这次，业务已经恢复。具体原因还没公布，我不猜。但有一件事值得记住。停摆的 100 多个小时里，有人在等提取公积金交房租。有人在等办贷款。他们不关心底层是存储坏了，还是数据库坏了。他们只关心一件事：什么时候能办。
这就是民生系统和普通业务的区别。普通系统挂了，大不了明天再用。公积金停了，可能影响一个家庭的现金流。所以容灾这件事，平时看着像技术指标。真到那一刻，它是一句承诺。系统坏了能顶上，数据不会丢。
方案里写 RTO 几秒，不如演练场上真断一次电。架构图画得再漂亮，不如值班的人知道第一步该干什么。系统会坏，这不稀奇。坏了之后多久能起来，才是一个团队真正的水平。我们这行做久了，容易把「高可用」当成一个参数。其实它最后落到一件很具体的事。别人最需要你的时候，你在线。
你们单位的容灾，上一次真演练是什么时候？评论区聊聊。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
参考信源：昆明市住房公积金管理中心 10 月 19 日、10 月 22 日通告。
