实现跨越IDC容灾，银行交易系统信创数据库如何结合数据库层和存储层容灾技术设计容灾方案？

【摘要】随着科技有国界的环境大趋势，中国企业正面临数据库等基础软硬件实现自主可控改造的实际需求。本文从实际需求出发，深入探讨数据库高可用容灾相关的技术方案。首先详细介绍了几类数据容灾使用的数据同步复制技术，阐述彼此特点和差异性，作为容灾建设选择依据，供用户参考。然后从容灾建设目标出发，探讨数据库容灾技术方案选择需要考虑的因素，如性能、高科用、成本和其他各类因素，并与容灾技术方案相互印证。文中还引入多个行业专家的评论，供用户参考。最后总结要基于实际需求选择合适的容灾技术。

【作者】孔再华，某银行单位 数据库架构师，具有丰富的数据库环境问题诊断和性能调优的经验。当前主要负责国产化数据库内部推广工作和智能运维（AIOps）工作。开发建设了某银行基础软件智能运维平台，实现基础软硬件的产品深度智能运维，引导传统运维向智能运维演进。

一、前言

在科技有国界的大环境下，中国企业面临着自主可控的压力，金融行业更是走在最前面。银行证券等企业面临着明确的基础软硬件设施国产化替换的时间表。然而企业不仅面临国产化替换走“量”的要求，还需要延续过去的IT基础架构建设的“质”，甚至在此过程中摒弃过去的弊端，设计更好的IT架构方案。

其中信息系统的容灾恢复能力是非常关键的建设指标。《银行业信息系统灾难恢复管理规范》是中国人民银行为加强银行业金融机构信息系统的灾难恢复能力，确保信息系统安全稳定运行而制定的一项行业标准。规范对灾难恢复的目标进行了分级，规定了不同级别的信息系统应达到的恢复时间目标（RTO）和恢复点目标（RPO），以确保关键业务功能在灾难发生后能及时恢复。

银行容灾等级通常根据业务中断的影响程度和重要性进行分类，以确保在发生灾难时，银行业务能够快速恢复，保障数据安全和业务连续性。根据中国金融行业的标准，容灾能力被划分为六个不同的等级，每个等级对应不同的恢复时间目标（RTO）和数据恢复目标（RPO）。其中一级容灾标准是最高级别，要求RTO在2小时内，RPO在15分钟内。

二、数据库容灾

数据库容灾技术主要解决两个问题：数据怎么跨机房同步（影响RPO）？灾难发生的时候如何恢复服务（影响RTO）？围绕这两个目标，目前比较主流的是采用数据库自身的复制同步技术和存储硬件复制技术这两种路线。

数据库复制技术

数据库主从同步复制技术几乎每个成熟的商业数据库都具备，自主可控的国产化数据库也基本具备相关功能。例如DB HADR、Oracle Data Guard、Mysql主从逻辑复制等技术就属于这一类。可能存在的问题是国产化数据库这方面的功能并没有机会经过多年应用和认证，可能存在不少缺陷需要解决。这是在企业“平替”过程中需要关注和重点测试的地方。我在使用某个国产数据库的过程中就遇到了不少主从数据同步相关的问题。

存储复制技术

存储硬件同步的技术相对简单，依赖底层存储硬件的复制能力，减少数据库的管理复杂性。灾难发生时，备中心只需要挂载上同步过来的数据盘，如本地启动数据库一般完成恢复即可。这种模式也称为冷备模式。除此之外也有软硬件结合的复杂方案，例如采用共享存储加文件系统集群等技术实现数据库多活。

数据库存储结合方案

目前还有一种数据库同步方案，结合存储复制和数据库回放能力，仅同步日志盘，备中心实时从日志盘回放数据，这种情况下数据是通过数据库回放机制完成同步，而不是依赖存储的数据盘复制，大大减少了数据中心之间需要的同步数据量。这种方案需要数据库回放能力扩展支持。

这种软硬协同方案在某国内大行已经落地。基础架构里面的gaussdb与华为存储软硬协同，实现了仅基于增量日志的存储同步复制方案，解决了中心间同步数据量的问题，并具备更高的可靠性。

三、容灾方案选择

那么究竟选择什么容灾方案比较合适？需要考虑哪些因素？

容灾方案建设，需要在多数据中心灾备建设定位的实际条件下，考虑性能、高可用性、成本等因素，选择合适的数据库容灾方案。

首先是多数据中心的定位。目前比较主流的是两地三中心。同城双中心，基本要求单独一个中心能够承载企业的所有业务。异地为灾备中心，预防地震等严重地质灾害情况下，该中心能够恢复部分主要业务。通常同城双中心的灾备要求是不丢数据，也就是RPO近乎为0。而异地的灾备中心，因为距离原因，如果实现数据同步复制会对主库产生比较大的性能影响，因此数据复制基本都是异步的。

当然还有很多其他多地多中心的建设方案。例如某些企业同城就有三中心，容忍单中心失联的情况下，剩下的中心能够自动承载所有业务，甚至不需要人工参与跨机房切换恢复。

在确定了数据中心的定位后，也就确定了中心之间容灾的硬性要求，也就是RPO、RTO的要求。这种情况下，在基于中心间的网络条件、距离等实际情况，才可以评估容灾方案。

关于数据库集群在多机房的容灾部署方案，社区针对这个问题发起了关于信创数据库容灾方案是选择跨机房部署还是多集群容灾的讨论，下面是部分观点：

来自某银行单位姚雅飞老师的观点认为：选择多集群容灾。1、技术原因：目前信创数据库不管是双机热备部署还是集群部署，厂商的设计目标一般满足数据库自身稳定运行，主要用于单数据中心内解决高可用的问题。在实际实施时考虑到双中心部署是原理上可行，但设计上由于厂商考虑满足数据库稳定运行，在外部参数的要求上比较苛刻，跨机房部署代价高、稳定性差。多集群方案本质上是两套独立的运行环境，中间通过数据库日志回放等技术完成数据同步，对单集群稳定运行基本没有影响。跨机房部署 技术复杂度高，出现问题在短时间内解决困难，多集群部署在出现问题时排查步骤相对简单，干扰因素少。2、增加了业务连续性风险：容灾最终要解决的是一些极端场景下的业务不间断，频率上发生的相对较少。跨机房部署增加了网络稳定性、延时等第三方带来的不确定性，数据库日常的稳定运行不能保证，认为增加了运行风险，带来业务的不稳定。多集群部署都是独立运行的集群，互相之间几乎没有干扰，对于原来的数据库仅是把事务日志发出一份给对方，稳定性几乎不受影响。

来自某证券公司的施斌老师的观点认为：1、采用多集群容灾部署方案优势，1）架构更加简单，机房间独立集群，不会因为某个机房故障，影响另外机房的集群。如果是多副本方案，主生产和同城副本间还是有一定影响，一方面会担心同城或者异地副本故障会影响到主生产，一方面也担心主生产故障的时候，同城或者异地副本无法正常接管。2）架构更加灵活，机房间独立集群，某些情况下同城集群可以单独激活提供一些测试或者演练的功能，而跨机房副本无法独立激活。3）部署更加灵活，跨机房副本方案，要考虑机房级故障多数派仲裁接管，仲裁服务器至少需要三机房部署，而多集群部署方案没这个限制。2、采用多集群部署方案不足之处，1）高可用RTO指标相对差一点；同集群间的副本数据同步延迟要比跨集群同步延迟更少。2）跨机房副本可以实现自动切换，多集群一般需要手动切换，切换需要更长的时间，操作也相对复杂。3）跨机房多副本方案投入的设备会更少一点，一般管理平台是共用一套，数据节点副本一套集群要满足最低3副本，算下来跨机房多副本更省机器。

来自某银行单位王兆坤老师认为：数据库产品，如果数据库属于分布式数据库，优先选择跨机房部署。由于分布式数据库一般都要求多数派，所以机房数量可能需要建议3个。如果只有两个机房，那需要必须增加多集群容灾方案。如果是集中式数据库，那建议使用成熟的跨集群容灾方案。就像RAC很少使用Extend Rac一样，一般都采用RAC+ADG。

来自某保险用户认为：两种方案都是可行的，对于不同的数据库类型，厂商给出的解决方案以及企业根据自身需求所选择的解决方案可能都是不同的。1、对于集中式数据库，以达梦数据库为例，两种方案都可以，一般如果企业出于成本考虑，大概率会选择在同城另一个机房通过搭建同步备库方式，实现故障自动切换，达到容灾目的，异地一般可以考虑异步复制搭建备库，一旦故障发生，可通过手动切换方式实现容灾，成本低，恢复快。2、对于分布式数据库，目前了解很多厂商的容灾方案也需要是一个集群，当然也可以选择单节点作为一个zone的灾备方案，或者是冷备，大部分推荐方案还是与生产同架构同节点数的集群，这种方案的好处是一旦生产发生故障，切换到容灾环境可以快速对外提供服务，减少业务影响，但所需要的成本也是比较高的，一般企业可以根据自身需求进行选择。

四、性能

了解容灾方案对于数据库性能的影响非常重要，尤其是同城双中心要求RPO=0的情况下，如何兼顾性能和高可用性。

首先了解数据库性能的关键点。数据库在运行过程中，所有的修改都是先落日志，然后才是数据落盘。事务提交成功是以日志落盘为准。而修改的脏数据首先是存在内存缓冲池里面，通过一次次检查点刷进磁盘。因此数据落盘可以认为是异步的。当数据库崩溃恢复的时候，数据库需要通过最后的检查点，加上日志的数据才能恢复出一个一致性的数据库出来。

在这个机制里面，影响当前数据库性能的最主要是日志的写入速度。只有日志被同步到备中心后，当前的数据库事务才算提交完成。

首先是网络延时因素。同城双中心或者多中心基本上布线距离都在70公里以内，这种情况下双中心网络延迟不超过1毫秒。而异地中心都得几百公里，网络延迟几十毫秒。即便是同城中心间的网络延时不超过1毫秒，在实际数据库容灾方案的实施过程中，我们依然能观察到数据库容灾后性能的明显差异。例如部分高并发的事务响应时间翻倍，夜间的批处理明显变得更久。

其次是网络带宽因素。数据中心间跨中心的网络访问很多，数据同步只是其中一项。不过这项从实际观察来看是属于最主要的。如果中心间网络带宽受限，那么网络堵塞的时候，对于数据库的性能影响会非常大，这是不得不考虑的点。

数据中心比较流行的容灾方案之一就是数据库的数据盘和日志盘都做同步复制。这种方案比较简单易实施，成熟性也没啥问题。但是在某些时候对于网络的压力非常大，甚至影响了关键业务。尤其是异地中心之间的网络带宽资源紧张，采用这种方式代价太高，需要权衡。

来自某银行单位姚雅飞老师的观点认为：使用过存算一体的解决方案，扩展不灵活，必须存算同时扩展。同时峰值容易叠加（IO峰值和计算峰值），容量规划较存算分离复杂。

来自某银行胡中豪老师的观点认为：存算一体的性能会比存算分离的性能好，存算分离更灵活，对于一些有灵活的扩缩容计算和存储资源的场景比较合适，比如公有云环境，在一些场景下不需要的计算资源可以选择关闭，需要结合应用性质具体情况具体分析。

五、高可用

灾备建设就是为了业务的高可用性。在RPO要求得到保证的情况下，RTO是下一个目标。

采用数据库自身复制技术的方案，备机通常是处于持续回放日志的热备，正常情况下切换比较快。但是出现数据库技术限制导致的日志回放速度慢延迟高等情况也很常见。我自己就遇到很多系统面临这样的问题，一直在推动厂商优化。这种情况发生的时候，备机切换的RTO就不能得到保障，实现不了分钟级切换的目标。

采用存储复制技术的方案，备机通常是冷备状态，数据库未启动。在切换的时候，备机需要挂载存储，启动数据库，完成崩溃恢复后，数据库才能恢复正常服务。正常情况下也能实现分钟级的恢复目标。然而我也遇到过数据盘多，挂载文件系统就需要几十分钟，数据库大，启动也需要几十分钟的系统。

这两种方案各有优缺点，也和数据库、存储等软硬件自身的能力有很大关系。在高可用性的选择上，需要结合业务系统数据库自身的交易特点，来选择合适的容灾技术，才能达到高可用性要求。

来自某银行董生的观点认为：从高可用容灾看，采用存算一体架构的数据库，大部分使用单集群拉远+异步复制模式，实际上这种方式下，在核心业务下多集群数据库强一致性几乎都大不到。在灾备切换的时候，基本上都是采用中断业务，等待数据传输完成的方式。而使用了存算分离后，可以利用专业企业存储的容灾备份能力，如快照、复制等，满足金融核心业务的数据保护需求。

六、成本

灾备方案成本包含很多方面，有软硬件费用、部署成本、运营管理成本等。存储复制和数据库复制从计算资源角度看没有区别，都是相同的硬件配置。存储复制方案部署需要存储卡和布线，但是扩缩容方便，便于资源整合。而数据库复制方案下，如果采用本地盘，那么可能存在磁盘空间浪费，也可能出现扩容困难，没有盘位的问题。

七、其他因素

容灾方案的成熟度也需要重点考虑。数据库不同，自身的复制能力，崩溃恢复能力差异很大。并不是原先的商业数据库方案就可以照搬不误。事实上任何一种容灾方案，都需要经过全面的压测，尽可能在上线前发现问题。

采用存储技术还有些其他特殊能力，例如基于快照技术快速备份和恢复、配额管理、流控等。在应用过程中用户可能需要这些能力。

下面这张表列举了数据库复制技术和存储技术在不同场景下的应用特点：

八、总结

容灾技术各有特点，并无优劣之分。没有完美的技术能够满足所有需求。在选型的过程中需要考虑到业务需求、系统特点、基础设施条件、应用成本等很多方面，才能选择到适合的容灾技术。

软硬件技术也一直在发展，软硬协同的能力也在增强。更多的灾备建设方案也在一一出现。双活、多活、分布式等各种数据库技术和存储结合，帮助用户实现更高性能扩展、更高可用性、更低成本的实践方案。

如有任何问题，可点击文末阅读原文，到社区原文下评论交流

觉得本文有用，请转发或点击在看，让更多同行看到