2022年1月15日，汤加火山突然剧烈喷发，火山喷发不仅使得汤加全境面临海啸、暴雨、洪水和强风的威胁，遮天蔽日的火山灰还严重阻碍了通信，使得汤加瞬间陷入了全境“失联”的状态，与外部世界的联系几乎完全中断。

　　在如此巨大的自然灾害的面前，传统的数据库高可用架构显得不堪一击——部署在汤加本地的机房不可避免地遭遇了断电，无法对外提供服务;关键的业务数据丢失，产生了不可估量的损失。地球的雷霆怒火面前，人类总是显得无比渺小，面对灾害无力回天。如何居安思危，通过有效的灾备方案，快速恢复生产、业务和服务，降低区域性灾难对企业数据的破坏，减少负面冲击，这是无数企业亟待解决的问题。

　　“两地三中心”解决方案就是为应对此类大范围自然灾害而提出的。“两地三中心”中的两地是指同城、异地;三中心是指生产中心、同城灾备中心、异地灾备中心。当单个地域的业务无法幸存时，可以采用同城双中心加异地灾备的“两地三中心”容灾备份解决方案，来应对大范围自然灾害导致的业务中断和数据丢失。金仓KingbaseES两地三中心高可用灾备解决方案可以完美解决各种场景下的灾备切换问题。下面，让我们来看看金仓KingbaseES的“两地三中心”实现方案。

　　金仓KES数据库的两地三中心架构

　　金仓KingbaseES集群支持的两地三中心容灾系统属于数据级的容灾，提供数据库软件的两地三中心解决方案，易用、易维护、可靠性高;并且用户可以在金仓KingbaseES的两地三中心方案上对应用和业务进行改造，构造应用级或业务级容灾系统。

　　定义：

　　两地三中心：一种业务连续性容灾方案。三数据中心并存的特性，能在任意两个数据中心受损的情况下保障核心业务的连续，大大提高容灾方案的可用性。

　　生产中心：对外提供服务。

　　同城灾备中心：通常在离生产中心几十公里的距离建立同城灾备中心，应用可在不丢失数据的情况下切换到同城灾备中心运行，是两地三中心容灾方案的第一级容灾保护。

　　异地灾备中心：通常在离生产中心几百或者上千公里的地方建立异地灾备中心，应对区域性重大灾难，实现异步复制灾备，是两地三中心容灾方案的第二级容灾保护。

　　SYNC：节点间同/异步关系，SYNC表示同步模式，数据会实时地同步传输到SYNC指向的节点。

　　ASYNC：节点间同/异步关系，ASYNC表示异步模式，数据会非实时地同步传输到ASYNC指向的节点，数据可能有一定的滞后性。

　　RTO(Recovery Time Objective)：从灾难发生到整个系统恢复正常所需要的最大时长。

　　RPO(Recovery Point Objective)：最多可能丢失数据的时长。

　　●能力

　　当前，人大金仓KingbaseES"两地三中心"提供如下功能：

　　1.数据同步，在多个副本之间进行数据同步，并基于同城短距离和异地远距离的不同场景提供最优的数据同步方案;

　　2.热备，备库可读，分担业务压力，识别读写事务并进行分发，降低单个数据副本的业务压力，提高整套系统的处理能力;

　　3.故障切换与故障恢复能力，保证7*24小时提供数据服务，各种软硬件故障下能够提供安全可靠的数据服务，最大程度提供数据可靠性和服务持续性;

　　4.独立备份，生产数据最后的保障，即使整套业务、数据库系统都无法恢复，还有最后的独立备份数据作为最终数据安全保障手段。

　　●方案优势

　　相比跨中心的同城容灾和跨地域的异地容灾，两地三中心容灾方案结合两者的优势，可以同时应对中心级别故障和地域级别灾难。

　　对于中心级别故障，容灾切换时保证数据库数据一致性。

　　对于地域级别灾难，该方案可将业务恢复至异地灾备数据，尽可能保全业务数据不丢失。

　　金仓KES两地三中心集群灾难恢复演练

　　●演练目标

　　通过实战演练，检验金仓KingbaseES两地三中心集群应对各种故障场景的能力：

　　A、是否支持自动故障切换和资源恢复

　　B、验证业务恢复的时长

　　C、检验数据同步延迟情况

　　●演练环境

　　此次金仓KingbaseES两地三中心集群灾难恢复演练采用5个数据库节点的模式，将生产中心、同城灾备中心放置于成都相隔30km机房，异地灾备中心放置于北京机房(成都至北京的直线距离约为1500km，绝大多数用户的灾备系统设计的灾备距离不会超过此值，最大限度地覆盖了客户的灾备场景)。服务器节点信息如下图：

　　●演练内容 | 生产中心整体故障

　　模拟生产中心主库和备库全部发生故障的场景：例如处于成都地域的生产中心机房遭到破坏，整体断电或者异常病毒造成设备瘫痪。

　　检验金仓KingbaseES两地三中心集群对上述故障的处理能力、故障处理能力边界及故障对业务的影响时长。

　　●自动故障切换

　　应用业务访问的生产中心故障，同城灾备中心经过集群多节点间心跳判断生产中心已不可访问。同城灾备中心迅速自动故障切换，提升本中心继续为应用提供服务，仅需秒级的业务恢复时长!

　　该阶段的容灾RPO等于0，RTO在几秒-几十秒内(可配置)。

　　●自动恢复加入集群

　　当生产中心整体发生故障时，切换后主库转移到同城灾备中心。之后，位于同城灾备中心的主库，将自动对生产中心的故障数据库进行恢复(例如此时生产中心已恢复供电或解决了设备瘫痪问题)。

　　先自动恢复node1，作为同步备库恢复。再自动恢复node2，作为异步备库恢复。在业务恢复期间，同城灾备中心始终对外提供服务，恢复过程对用户无感，RTO/RPO=0!

　　同时，当生产中心整体恢复后，又可作为当前同城灾备中心的同城容灾节点，提供与之相应的故障处理能力，业务又回到开始的同城双中心均可访问的场景。

　　●演练内容 | 生产中心和同城灾备中心全部故障

　　模拟生产中心和同城灾备中心全部故障的场景：例如处于成都的生产中心和同城灾备中心因不可抗力的因素整体遭到破坏。

　　该阶段的容灾RPO取值为 0 ~ 数秒/数分钟。取决于业务带宽规划值和业务高峰/低峰区。RTO一般建议用户手动切换执行，自动切换在数分钟内。

　　位于北京的异地灾备中心可手动/自动切换至对外提供服务的状态，作为数据系统最后的保障。此场景一般从应用层面系统性地规划应用/业务系统和数据系统整体的计划迁移。金仓为此类灾难级恢复也提供了基础保障。

　　●演练内容 | 实测生产中心、同城灾备中心、异地灾备中心数据差异

　　通过实战演练，查看生产中心、同城灾备中心、异地灾备中心数据同步延迟情况，直观了解实际地域距离、网络带宽、网络延迟等对数据同步的影响。客户可以根据自己的业务场景来决定容灾环境的设置标准(网络带宽、容灾距离等)。

　　本次测试主要关注数据差异值的范围。

　　测试1：kbbench灌1000万数据

　　./kbbench -Usystem -p10001 -i test -s100-s 100比例因子，会在内置的一个10w行数据表放大100倍，将在kbbench_accounts表中创建10,000,000行。共计数据量：Total data size: 1554 MB产生的数据库日志量：

　　test=# selectsys_size_pretty(sys_wal_lsn_diff('0/80008A8','0/56888B20'));sys_size_pretty-----------------1257 MB

　　(1 行记录)

　　比较运行过程中生产中心与同城灾备中心的同步备机日志差异：

　　●日志无差异;

　　●数据库的同步机制在业务层面上是保证完全一致。

　　select application_name,sys_wal_lsn_diff(sys_current_wal_flush_lsn(),flush_lsn)/1024/1024 as MB from sys_stat_replication;application_name | mb------------------------------+------------------------node2 | 0.00000000000000000000node3 | 0.00000000000000000000

　　(2 行记录)

　　比较运行过程中同城灾备中心与异地灾备中心的异步备库日志差异：

　　●异步备库处于同城，级联(串联)的特性极大缓解了生产中心到同城灾备中心的网络压力，(在CPU、IO等未达到瓶颈时)即使是异步模式，也可以实时同步级联节点完成数据同步。

　　●异地灾备中心的数据库，日志差异较大，最高峰达984M左右的差异(差异值主要取决于距离和带宽、网络延迟。因此，需提前规划好异地的带宽配置情况，以满足累积日志平均每天近饱和的传输完。金仓可利用日志压缩功能，为用户更多地节省昂贵的异地专用带宽)。

　　test=# selectapplication_name,sys_wal_lsn_diff(sys_last_wal_receive_lsn(),flush_lsn)/1024/1024as MB from sys_stat_replication;application_name |mb------------------------------+------------------------node4 | 0.00000000000000000000node5 |984.2698364257812500test=# select application_name,sys_wal_lsn_diff(sys_last_wal_receive_lsn(),flush_lsn)/1024/1024as MB from sys_stat_replication;application_name | mb------------------------------+------------------------node4 | 0.00000000000000000000node5 |754.11923456456578460(2 rows)

　　ps：测试过程中，异地带宽已占满20MB/s，证明高峰期数据的差异带宽占了很大的决定性作用。

　　测试2：模拟500客户端并发测试，运行5min

　　./kbbench -Usystem -p10001 -r -j 64 -c 500 -T 300 test

　　运行结束后产生日志

　　：test=# select sys_size_pretty(sys_wal_lsn_diff('0/9C040C80','0/BC3CE7A0'));sys_size_pretty-----------------516 MB

　　(1 行记录)

　　比较运行过程中生产中心与同城灾备中心的同步备机日志差异，日志无差异。

　　test=# select application_name,sys_wal_lsn_diff(sys_current_wal_flush_lsn(),flush_lsn)/1024/1024 as MB from sys_stat_replication;

　　application_name | mb

　　------------------------------+------------------------

　　node1 | 0.00000000000000000000

　　node3 | 0.00000000000000000000

　　(2 rows)

　　比较运行过程同城灾备中心异步备库与异地灾备中心异步备库日志差异，异地容灾节点趋近于0，可以看到在异地带宽满足正常业务流量时，波动非常稳定。

　　test=# select application_name,sys_wal_lsn_diff(sys_last_wal_receive_lsn(),flush_lsn)/1024/1024 as MB from sys_stat_replication;

　　application_name | mb

　　------------------------------+------------------------

　　node4 | 0.00000000000000000000

　　node5 |0.8233871459960938

　　(2 rows)

　　小结

　　在实际演练过程中，还有其他几类场景，金仓KingbaseES两地三中心集群故障处理结果总结如下：

　　●生产中心和同城灾备中心可以保证数据无丢失的RPO=0、RTO=秒级的高可用容灾方案。在各类场景的演练均能做好数据不丢，服务不断，无须人工干预的企业级处理标准(对应信息安全技术信息系统灾难恢复规划6级)。

　　●异地灾备中心数据差异有一定的波动。差异值主要取决于距离和带宽、网络延迟，金仓会提前帮助客户规划好异地的带宽配置情况，以满足当前业务系统评估日志每天的生成量，制定合理的带宽值。同时利用日志压缩功能，可以压缩日志在50-70%以上，可为用户节省昂贵的异地专用带宽。在合理的满足业务流量需求上，RPO可以达到秒级。RTO推荐用户手动执行，自动切换异地灾备默认RTO在数分钟内完成。

　　应用案例

　　当前，金仓KingbaseES“两地三中心”方案已在x中心核心业务系统中成功应用，为关键政务数据的安全保驾护航。

　　系统于2020年底上线并稳定运行后，该中心技术负责人致电金仓，充分肯定金仓方案、产品及服务团队的专业性和先进性，对金仓在项目中的勤奋务实与专业精神予以赞扬并表示感谢。

　　结语

　　随着互联网的不断发展和电子政务建设步伐的迈进，各行各业不断加紧开展线上业务，越来越多的用户核心业务都要求二十四小时不断网，持续运行，对数据安全提出了更高的要求。

　　但是，地震、海啸、龙卷风、火山喷发、泥石流、山体滑坡，以及气候变化引发的干旱、洪水.....如同达摩克里斯之剑一般悬在我们头顶，随时威胁着数据安全，影响着人类文明的进程。身处地球，没有谁能置身事外。谁都无法预测这些自然灾难将会何时降临，切断服务、摧毁业务核心数据。这就需要我们具备应对各种灾难、故障场景的能力，而金仓KingbaseES两地三中心集群将会是您最好的选择。

　　完善的灾备方案、智能的故障自动恢复和资源转移、瞬时的业务恢复时长......金仓KingbaseES两地三中心集群，与您一起应对各种灾难场景，带您避免自然灾害对业务的毁灭性打击!