据媒体报道，12月18日，阿里云香港PCCW机房制冷设备发生故障，直接影响了香港地域可用区C的云服务器ECS、云数据库、存储产品（对象存储、表格存储等）、云网络产品（全球加速、NAT网关、VPN网关等）等云产品的使用。云产品的大面积停摆，使得托管在该地域的众多服务项目无法访问，网络上已有多位用户反馈，此次事故造成宕机和服务不可用时间超过了24小时，损失巨大。

（图片来源：阿里云官网）

作为底层数据服务平台，确保平台的安全、稳定运行，是其最核心、最关键的工作之一。而超过24小时的持续服务故障，不仅对云服务厂商敲响了警钟，也是对用户信赖的极大挑战。如果数据的安全储存都无法保证，那么业务的稳定运行就无从谈起。

而在此次阿里云宕机事件发生之后，我们也不止一次叩问自己，如果金仓数据库遭遇类似情况，是否也会宕机？是否也会导致客户业务瘫痪？

金仓容灾方案

作为中国领先的数据库产品与服务提供商，人大金仓一直致力于为用户搭建完善的容灾备份机制，保障各种灾难/故障场景下业务的7*24无中断持续运行。基于此，人大金仓推出了同城双中心容灾和两地三中心容灾等多中心灾备方案，为大型金融、政务、电力等行业用户提供灵活敏捷、安全稳定、灾备管理融为一体的先进数据中心解决方案，保证金仓数据库在遭遇机房故障、地区性灾难等情况时不宕机，维持用户业务的稳定持续运行！

同城双中心容灾方案

在离生产中心几十公里的距离建立同城容灾中心，双中心具备基本相同的业务处理能力并通过高速链路实时同步数据，应用可在不丢失数据的情况下切换到同城容灾中心运行。日常情况下可同时分担业务及管理系统的运行；灾难情况下自动应急切换，保证数据零丢失、服务零中断，以及业务的持续性。

两地三中心容灾方案

结合同城容灾与异地容灾的架构方案，同时部署同城的双中心与异地的灾难备份中心。既有同城容灾的高可用性，又有异地容灾的灾难备份能力。避免极端情况发生所带来的数据丢失问题。当生产中心发生故障无法提供服务时，优先切换到同城的灾备中心继续对外提供服务，保证数据零丢失与服务连续运行。一旦同城的双中心都处于受灾范围，无法提供服务时，可以选择由异地灾难备份中心对外提供服务。

应用案例

为适应互联网业务的快速增长，保障银行各业务安全稳定地不间断运行，提高市场竞争力，同时满足监管机构的监管要求，建设数据中心灾备体系正在成为商业银行的共同选择。

在新疆某金融机构结算系统项目中，人大金仓围绕金融领域监管要求与业务连续性目标，基于金融系统的业务特征和“同城容灾、数据同步、快速切换、数据可靠、持续运行、服务可用”等关键需求，不断优化数据中心灾备体系架构，最终构建了一个安全、稳定、低成本、高可用的同城双中心高可用部署方案。

该容灾系统在同城分别部署生产中心和同城灾备中心两个中心，当生产中心故障后同城灾备中心能够接管业务。生产中心采用1套一主两备读写分离集群，以流复制同步方式同步数据至同城灾备中心。同城灾备中心距离生产中心不远，部署三个备节点，备节点之间采用异步同步方式。

第三方仲裁节点即中心级仲裁observer节点，部署在单独的设备之上，与生产中心和同城灾备中心之间网络独立。跨中心的快速故障切换依赖部署于第三中心的仲裁节点。

系统正常运行时使用生产中心，而当生产中心出现全局故障后，同城灾备中心自动切换为主节点对外提供服务，主节点下挂节点自动切换为同步模式。当同城灾备中心作为灾备中心使用时，数据库属于只读模式，同城灾备中心与生产中心同步节点可参与实时性高的读请求对外提供服务，下挂的两个备节点可承担非实时性查询类业务（报表类、数据导入导出等日常业务）数据需要。

服务器节点信息

网络规划

此外，项目还引入了人大金仓数据库监控系统KMonitor，通过在数据库服务中部署探针，监控系统在运行过程中的各类故障，及时、精准发送预警信息。通过完备的故障风险管控策略，防患于未然。

在人大金仓定制化同城双中心高可用部署方案下，生产中心和同城灾备中心可以保证数据无丢失的RPO=0、RTO=秒级的高可用容灾方案，从根本上避免了系统宕机事件的发生！

该金融结算项目落地后，在各类场景下的多次演练中，均能做到数据不丢，服务不断，无须人工干预的企业级处理标准（对应信息安全技术信息系统灾难恢复规划6级）

结语

信息安全是国家安全的重要组成部分，而对于信息安全、数据安全而言，灾备则是最基础最刚性的技术需求。可以说几乎所有的信息资产都需要灾备保护，以确保在意外故障的情况下信息系统的正常稳定运转。

作为国产数据库领域的国家队，人大金仓一直在数据库领域默默耕耘，始终围绕数据库核心技术，通过自主创新培育持续发展的原动力，为国家信息化产业安全事业贡献力量。未来，人大金仓将持续践行数据库领域国家队的使命，踔厉奋发，笃行不怠，为各行业数字化场景提供数据存储计算支撑，为用户的数据安全保驾护航！