2022年1月15日，汤加火山突然剧烈喷发，火山喷发不仅使得汤加全境面临海啸、暴雨、洪水和强风的威胁，遮天蔽日的火山灰还严重阻碍了通信，使得汤加瞬间陷入了全境“失联”的状态，与外部世界的联系几乎完全中断。yyy大手笔网—中国第一文化门户网站
在如此巨大的自然灾害的面前，传统的数据库高可用架构显得不堪一击——部署在汤加本地的机房不可避免地遭遇了断电，无法对外提供服务；关键的业务数据丢失，产生了不可估量的损失。地球的雷霆怒火面前，人类总是显得无比渺小，面对灾害无力回天。如何居安思危，通过有效的灾备方案，快速恢复生产、业务和服务，降低区域性灾难对企业数据的破坏，减少负面冲击，这是无数企业亟待解决的问题。
“两地三中心”解决方案就是为应对此类大范围自然灾害而提出的。“两地三中心”中的两地是指同城、异地；三中心是指生产中心、同城灾备中心、异地灾备中心。当单个地域的业务无法幸存时，可以采用同城双中心加异地灾备的“两地三中心”容灾备份解决方案，来应对大范围自然灾害导致的业务中断和数据丢失。金仓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一般建议用户手动切换执行，自动切换在数分钟内。位于北京的异地灾备中心可手动/自动切换至对外提供服务的状态，作为数据系统最后的保障。此场景一般从应用层面系统性地规划应用/业务系统和数据系统整体的计划迁移。金仓为此类灾难级恢复也提供了基础保障。
●演练内容|实测生产中心、同城灾备中心、异地灾备中心数据差异
通过实战演练，查看生产中心、同城灾备中心、异地灾备中心数据同步延迟情况，直观了解实际地域距离、网络带宽、网络延迟等对数据同步的影响。客户可以根据自己的业务场景来决定容灾环境的设置标准（网络带宽、容灾距离等）。本次测试主要关注数据差异值的范围。
