180秒揭秘数据库金融级灾备架构

2020-05-29 00:00:00 数据节点城市子网异地

无论在中国还是海外，金融行业的数据安全已经成为了监管机构的首要要求。在中国，银行核心系统安全一直是我国银监会所关注的重点，对于大部分银行数据中心，监管机构目前提出了对于数据安全和数据高可用的“两地三中心”以及“双活”的能力。“两地三中心”即生产数据中心、同城灾备中心和异地灾备中心建设方案。这种模式下，两个城市的三个数据中心互联互通，如果一个数据中心发生故障或灾难，其他数据中心可以正常运行并对关键业务或全部业务实现接管。如今，⼀些大型银行，甚⾄已经实现了“三地五中心”。“双活”数据中心就是同个城市部署两个数据中心，多活一方面是多中心之间地位均等，这样做的优势是：

1）多中心协同工作，并行提供服务，充分利用资源；

2）⼀个数据中心出现灾难时，用户“故障无感知”，其它数据中心正常使⽤。

SequoiaDB 巨杉数据库是一款开源的金融级分布式关系型数据库，主要面对高并发联机交易型场景提供高性能、可靠稳定以及无限水平扩展的数据库服务。当前已经有近百家家银行机构与上百家企业级用户在生产环境大规模使用 SequoiaDB 巨杉数据库取代传统数据库。针对某大型银行企业，巨杉分布式数据库为其数据库实现了异地灾备的架构保障数据安全。

本文将围绕下面三个方面介绍 SequoiaDB 灾备架构：

1）SequoiaDB“两地三中心”在线灾备系统架构原理

2）如何实战搭建

3）如何实现灾备切换与恢复

SequoiaDB异地多活灾备架构

SequoiaDB 已经在内部实现了容灾备份以及“双活”的机制，主要特点包括：

异地容灾：异地的容灾和备份，保证数据安全，中心间距离超过1000km以上；满足金融机构“两地三中心”的监管需求。
同城双活：同城双中心的数据准实时同步，保证数据一致；双中心数据可以实现同时读写，大大提升读写效率；中心切换 RTO 小于 10分钟。
数据压缩机制：节约带宽资源，加快同步和备份过程。
更便捷的灾备管理：系统集群中统一管理灾备中心，简化了维护成本，帮助用户更快上手

图1 异地容灾部署架构图

该架构是基于 SequoiaDB 的三副本方案构建的异地容灾。在同城灾备的基础上，在异地机房单独部署一套 SequoiaDB 集群作为异地灾备集群。

同城灾备是基于 SequoiaDB 的三副本方案构建的同城灾备，其中两副本部署在本机生产环境中，一副本部署在灾备环境中，整个集群跨越生产环境与灾备环境两个机房。异地集群只保持单副本，两地间结构化数据的同步通过传输同城灾备集群日志到异地灾备集群，然后通过重放日志记录的方式实现结构化数据的同步。

为了保证灾备环境与生产环境的数据保持实时一致，开启巨杉数据库中数据同步强一致性的功能。每次进行数据更新时，只有当存活的节点全部同步完成后，应用端才回收到更新成功的返回，这样就能在大程度上保证了数据不丢失。

搭建“两地三中心”实战

1. 两地三中心环境信息

2. 系统部署

图2. 系统部署图

主机1，2，3 部署 SequoiaDB 的编目、协调和数据节点，数据节点的数据路径与上述图上的磁盘对应，编目和协调节点共享使用 disk1 即可。在当前的布署中，城市A为业务的主系统，城市B为在线异地灾备系统。

3. 关键指标和参数

城市A和城市B之前的网络带宽和延时

该指标非常重要，可能会影响系统关键参数的配置。低带宽和高延时的情况下，城市B的节点同步数据就非常缓慢，若在业务要求数据强一致的情况下，会严重影响业务的性能。在业务要求弱一致的情况下，可能会发生城市B的节点数据远远落后于城市A的节点数据，从而引发城市B的节点向城市A的节点进行全量同步，导致业务性能下降。建议城市A和城市B之间的网络带宽在1000Mb/S以上，延时在十毫秒级以内。

业务一致性策略

针对集合的一致性策略（创建集合时的属性 ReplSize）：

a) 在取值为1时，业务只要写完主节点就返回，性能得到保障，但异地灾备系统的数据会出现较大延时，在城市A整体故障时，会引发数据丢失；

b) 在取值为-1时，业务写主节点后，需要等待所有正常的节点完成数据同步后才返回，性能会受制于城市A与B之间的网络情况。在城市A发生整体故障时，数据丢失风险非常小；

c) 在取值为2时，业务写主节点后，需要等待至少其它1个节点完成数据同步后才返回。由于同城内的网络优于城市间，因此，该情况下保证了同城内节点间的数据同步，在城市A发生整体故障时，数据丢失风险还是较大。建议集合的一致性策略即ReplSize属性取值为-1。

节点数据故障时的处理策略

当城市B的节点出现节点异常或数据严重落后于城市A的节点时，城市B的节点就需要进行数据异常的处理，目前的数据异常处理有3种：

a) 全量同步：会占用大量的带宽，会对业务性能造成影响，建议是在业务低谷期才开启；

b) 节点停止：节点停止运行；

c) 节点保持运行，不进行全量同步，但数据也不对外提供服务：主要是用于保持分区组的心跳和选举稳定性，可以让集群整体可用。对应的节点配置参数为“dataerrorop”，取值0表示c，1表示a，2表示b。建议配置为0，当有节点出现数据故障时，在业务低谷期修改参数为1，并动态生效（执行reload）以让节点自动全量同步，也可以保证减少对业务的影响。

异地在线灾备系统搭建

1. 灾备工具对应在版本的安装根路径（本系统中为 /opt/sequoiadb ）下

tools  |---dr_ha  |    |----cluster_opr.js  |    |----init.sh  |    |---split.sh  |    |---merge.sh  |    |---readme.txt

2 . 将上述机器根据城市划分为2个分组SUB1（host1，host2）和SUB2（host3），并在 host1 和 host3 上进行配置的修改

修改 host1 上的 cluster_opr.js 文件

/* 机器登入用户名定义 */if ( typeof(USERNAME) != "string" ) { USERNAME = "sdbadmin" ; }/* 机器登入密码定义 */if ( typeof(PASSWD) != "string" ) { PASSWD = "sdbadmin" ; }/* 子网1机器定义，必须为字符串数组 */if ( typeof(SUB1HOSTS) == "undefined" ) { SUB1HOSTS = [ "host1", “host2” ] ; }/* 子网2机器定义，必须为字符串数组 */if ( typeof(SUB2HOSTS) == "undefined" ) { SUB2HOSTS = [ "host3" ] ; }/* 协调节点定义，如果协调节点已经在 Catalog的编目组信息中，则此处填写一个可用Coord即可 */if ( typeof(COORDADDR) == "undefined" ) { COORDADDR = [ "host1:11810", “host3:11810” ] }/* 当前子网取值, 1表示子网1，2表示子网2，其它取值非法 */if ( typeof(CURSUB) == "undefined" ) { CURSUB = 1 ; }/* 是否激活该子网集群，取值 true/false */if ( typeof(ACTIVE) == "undefined" ) { ACTIVE = true ; }

修改 host3 上的 cluster_opr.js 文件

/* 机器登入用户名定义 */if ( typeof(USERNAME) != "string" ) { USERNAME = "sdbadmin" ; }/* 机器登入密码定义 */if ( typeof(PASSWD) != "string" ) { PASSWD = "sdbadmin" ; }/* 子网1机器定义，必须为字符串数组 */if ( typeof(SUB1HOSTS) == "undefined" ) { SUB1HOSTS = [ "host1", “host2” ] ; }/* 子网2机器定义，必须为字符串数组 */if ( typeof(SUB2HOSTS) == "undefined" ) { SUB2HOSTS = [ "host3" ] ; }/* 协调节点定义，如果协调节点已经在 Catalog的编目组信息中，则此处填写一个可用Coord即可 */if ( typeof(COORDADDR) == "undefined" ) { COORDADDR = [ "host1:11810", “host3:11810” ] }/* 当前子网取值, 1表示子网1，2表示子网2，其它取值非法 */if ( typeof(CURSUB) == "undefined" ) { CURSUB = 2 ; }/* 是否激活该子网集群，取值 true/false */if ( typeof(ACTIVE) == "undefined" ) { ACTIVE = false ; }

3. 执行初始化在 host1 的安装目录下执行如下命令

>sh tools/dr_ha/init.shBegin to check args...DoneBegin to check enviroment...DoneBegin to init cluster...Begin to update catalog and data nodes's config...DoneBegin to reload catalog and data nodes's config...DoneBegin to reelect all groups...DoneDone

4. 在 host3 的安装目录下执行上述相同的命令

至此，异地在线灾备系统已搭建完成。

灾备切换与恢复

1. 灾备切换

当城市A的所有机器发生故障时，此时业务中断，需要进行异地灾备系统的切换，并对业务提供所有服务。

图3. 灾备系统切换

修改 host3 的cluster_opr.js中的配置项

/* 是否激活该子网集群，取值 true/false */if ( typeof(ACTIVE) == "undefined" ) { ACTIVE = true ; }

> sh tools/dr_ha/split.shBegin to check args...DoneBegin to check enviroment...DoneBegin to split cluster...Stop 11820 succeed in host3Start 11820 by standalone succeed in host3Change host3:11820 to standalone succeed……Stop all nodes succeed in host3Restart host3 all nodes succeedDone

此时城市B的灾备系统已完成切换，成为独立的业务集群，并且对外可以提供任何服务。

城市A的机器在故障恢复后，需要在 host1 上修改 cluster_opr.js 中的配置

/* 是否激活该⼦⽹集群，取值 true/false */if ( typeof(ACTIVE) == "undefined" ) { ACTIVE = false ; }

并在 host1 的安装目录下执行 sh tools/dr_ha/split.sh 命令，让其成为独立的只读集群，进行相应的数据修复。

2. 灾备修复

当城市A的所有故障都完成修复，此时需要将上述2个城市中已分离的独立集群进行合并，形成异地在线灾备系统，恢复初的状态。用户可以在 host3 和 host1 的安装目录下同时执行命令。

> sh tools/dr_ha/merge.shBegin to check args...DoneBegin to check enviroment...DoneBegin to merge cluster...Stop 11820 succeed in host3Start 11820 by standalone succeed in host3Change host3:11820 to standalone succeedRestore group[SYSCatalogGroup] to host3:11820 succeedRestore group[group1] to host3:11820 succeedRestore group[group2] to host3:11820 succeedRestore group[group3] to host3:11820 succeedRestore group[SYSCoord] to host3:11820 succeedRestore host3:11820 catalog's info succeedUpdate host3:11820 catalog's readonly prop succeed……Start all nodes succeed in host3Restart host3 all nodes succeedDone

至此城市A和城市B被分离的集群又重新形成了一个异地在线灾备系统，恢复完成。

总结

在金融级强监管的要求之下，无论是“两地三中心”还是数据的容灾备份等要求，使得金融级的分布式数据库不断地在数据安全方面进行新的创新。未来，分布式数据库作为数据管理的核心枢纽，也将不断提高数据安全、数据可用性方面的功能。通过双活、多活以及高可用灾备等机制不断创新，数据库安全将会提升一个新的台阶。

点击阅读原文，获取更多精彩内容~

相关文章