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

10 月 19 日凌晨两点四十四分，昆明公积金发了一条通告。存储系统集群节点故障，数据库运行异常。线下柜面和线上渠道，全部暂停。10 月 22 日，恢复时间定了。23 日 9 点柜面恢复，24 日零点线上恢复。从 19 日凌晨算起，柜面停了 102 小时，线上停了 117 小时。
![昆明市住房公积金暂停服务.png](https://developer.qcloudimg.com/http-save/yehe-12362123/75b59909c1155a3b0a0a2a38cc0ae7f9.png)

缴存、提取、贷款、查询、结算，都压在同一套核心库上。底下坏了，上面全停。我看到这条新闻，第一反应不是「怎么又崩了」。我想的是：一个节点故障，怎么能拖这么久？

## 通告里的两句话，有先后

「存储系统集群节点故障」，「数据库运行异常」。这两句不是并列关系。按字面读，存储先出问题，数据库跟着异常。这个链条我熟。数据库跑在存储上，存储一抖，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 日通告。



10 月 19 日凌晨两点四十四分，昆明公积金发了一条通告。存储系统集群节点故障，数据库运行异常。线下柜面和线上渠道，全部暂停。10 月 22 日，恢复时间定了。23 日 9 点柜面恢复，24 日零点线上恢复。从 19 日凌晨算起，柜面停了 102 小时，线上停了 117 小时。

数据库容灾该补什么课？公积金停摆102小时的4点反思

昆明公积金系统因存储集群节点故障，柜面停摆102小时、线上117小时。我从通告拆故障链，聊清有集群不等于有容灾，给出故障域、切换、回切和数据校验的验收问题，附一份能落地的演练记录表。

数据库

昆明公积金系统因存储集群节点故障停摆102小时，暴露容灾架构深层问题。文章剖析故障链，强调集群不等于容灾，需通过故障域分析、真演练、回切验证来保障高可用，并为数据库迁移与容灾验收提供实用避坑清单。

服务器

防火墙

容灾

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

数据库容灾该补什么课？公积金停摆102小时的4点反思-腾讯云开发者社区-腾讯云

数据库容灾该补什么课？公积金停摆102小时的4点反思

数据库容灾该补什么课？公积金停摆102小时的4点反思

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐