国产分布式数据库灾备高可用实现

最近在进行核心业务系统的切换演练测试，就在想一个最佳的分布式数据库高可用部署方案是如何保证数据不丢、系统可用的，做到故障时候可切换、可回切，并且业务数据的一致性。本文简要介绍了OceanBase数据库和GoldenDB数据库在灾备高可用的部署方案，以参考。

在生产环境数据库相关的变更操作时，可能因为DML或DDL操作导致数据被篡改或者表结构不可逆，此时需要数据库提供一种高可用机制和能力恢复到变更前的时点，以保证业务的连续性。主要有两种思路，一种是闪回功能将数据恢复到变更操作的时点；另一种是延迟复制，备节点和主节点之间的数据复制设置一个延迟时间，主节点出现逻辑上的误操作时，利用备节点延迟同步来恢复数据。

1）闪回功能

国产数据库中很多已支持闪回功能，比如TiDB、GaussDB、OpenGauss、OceanBase等。以GaussDB为例在Ustore引擎中闪回功能，通过参数enable_recyclebin控制回收站的实时打开和关闭。并通过recyclebin_retention_time参数设置回收站对象保留时间，超过该时间的回收站对象将被自动清理。

2）延迟复制

在主备部署架构的数据库中，基本都能实现延迟复制功能，像MySQL、OpenGauss这样的单实例数据库。比如在OpenGauss数据库中的延迟复制，允许将回放延时一段指定的时间后进行回放，提供一份可查询一段时间之前的数据副本；在MySQL数据库中通过MASTER_DELAY来配置主节点和备节点的复制延迟。

在集中式主备架构的延迟复制实现基础之上，分布式数据库在架构上如何实现延迟复制以保证高可用。对于分布式架构的难点之一是如何确保故障场景下各个分片之间的数据一致性。对于国产分布式数据库OceanBase、GoldenDB以及TiDB等，已经有不少成熟的方案。本文将重点介绍OceanBase数据库的物理备库方案和GoldenDB数据库的DRSP灾备集群方案，不仅仅实现了延迟复制功能，而且满足灾备切换方案的多样性和灵活性，如异地灾备方案和孤岛验证方案。

1、OceanBase数据库物理备库方案

OceanBase数据库支持多副本的高可用容灾方案，同时也支持基于物理备库的准实时热备份方案。当生产主库出现故障时，备库可以接管服务，最大限度降低服务停机时间，减少可能带来的数据损失。从V4.1.0版本开始，OceanBase数据库按照租户粒度提供物理备库能力，分为主租户和备租户：主租户是业务运行的租户，提供完整的数据库服务能力；备租户只提供容灾和只读服务能力。

OceanBase的物理备库主要通过日志传输服务和日志存储服务来完成日志的传输及存储，并通过日志回放服务来保证主备租户数据的一致，其中：

日志传输服务在主租户和备租户之间实时同步 Redo 日志。当前OceanBase数据库物理备库仅提供异步同步模式。
日志存储服务为物理备库提供高可用、高可靠的日志存储和读写能力。
备租户写入日志存储服务的日志会通过日志回放服务实时或延后地应用到内存的MemStore之中，以保证主租户和备租户的数据完全一致。

1.1 物理备库的部署方案

OceanBase物理备库的部署方案中，可以按照集群中主租户和备租户进行不同的组合，主租户和备租户可以在同一个集群中，也可以在不同的集群中。典型的部署方案有几种：

集群中仅有主租户或备租户：包括多个OceanBase集群，业务租户在一个集群，备租户在另外一个集群，中间采用异步复制的方式，满足异地容灾的高可用需求；
集群中既有主租户又有备租户：多中心多活的部署架构，不同地域之间的集群互为主备；
主租户和备租户在同一个集群中：主备租户在同一个集群中进行管理，适用于数据库变更或升级的场景，又不需要增加额外的管理集群资源。

在这里插入图片描述

第三种部署架构适合租户在升级或者数据库变更操作前，在备租户中保留一份数据库快照，将被租户的同步暂停。业务在主租户上进行升级变更等操作，如果变更异常，将备租户切换为主租户对外提供服务，以保证业务的连续性。

1.2 物理备库的日志传输

物理备库通过日志传输服务在主租户和备租户之间实时同步Redo日志，备租户既可以通过主租户的日志归档来获取日志，也可以通过网络直连主租户所在的集群来获取日志。

基于日志归档的物理备库：主租户开启日志归档将日志归档到目标存储（OSS/NFS）中，备租户恢复归档日志实现数据同步；需要主租户和备租户开启归档模式。
基于网络传输的物理备库：备租户直接通过网络连接主租户或其他备租户读取日志，类似于MySQL数据库的复制方式。

在这里插入图片描述

在基于网络传输的部署模式下，备租户从主租户读取的日志，既可以是主租户的在线日志，也可以是主租户的归档日志。同时这种模式下支持集群级别的限速。

1）暂停或开启日志同步

#登录备租户或所在集群的sys租户，执行命令暂停租户日志同步
ALTER SYSTEM RECOVER STANDBY [TENANT = tenant_name] CANCEL ;
#登录备租户或所在集群的sys租户，执行命令开启租户日志同步
ALTER SYSTEM RECOVER STANDBY [TENANT = tenant_name] UNTIL UNLIMITED;

需要注意的是，暂停日志同步后，备租户不会再从主租户同步任何日志，尽量避免因暂停日志同步而导致的备租户日志断流。

2）查看日志同步进度

#执行SQL查看备租户同步进度
SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, SCN_TO_TIMESTAMP(SYNC_SCN) 
FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'standby_tenant';
+----------------+-----------+-------------+----------------------------+
| TENANT_NAME    | TENANT_ID | TENANT_ROLE | SCN_TO_TIMESTAMP(SYNC_SCN) |
+----------------+-----------+-------------+----------------------------+
| standby_tenant |      1004 | STANDBY     | 2023-04-14 16:38:53.938774 |
+----------------+-----------+-------------+----------------------------+
1 row in set

3）设置同步限速

适用于集群之间备租户同步限速

standby_fetch_log_bandwidth_limit：用于设置备租户所在集群中，可用于备租户从主租户或源端租户进行日志同步的所有带宽的总和。
_server_standby_fetch_log_bandwidth_limit：用于设置备租户所在集群的单个 OBServer 节点中，可用于备租户从主租户或源端租户进行日志同步的带宽。

1.3 日志存储服务

OceanBase数据库中日志存储服务使用Paxos协议实现高可用，其中主租户和备租户中的日志存储服务使用了不同的工作模式：

APPEND模式：主租户上使用APPEND模式。在该模式下，主租户日志流的Leader会接收事务、DDL等上层模块写入的数据，并将这些数据在主租户的多个副本之间使用 Paxos 协议进行同步并持久化。
RAW_WRITE模式：备租户上使用RAW_WRITE模式。在该模式下，备租户日志流的Leader拒绝任何上层模块直接写入的数据，仅允许通过日志传输服务从主租户同步物理日志，且这些物理日志的内容、LSN、SCN等信息均由主租户生成。

在数据同步过程中，每一条日志都会在主租户上生成一组唯一的LSN和SCN值。其中，LSN用于定位这条日志在存储服务中的物理位置信息；SCN用于代表这条日志在存储服务中的时序关系，上层服务可以使用SCN值对多个日志流之间的日志进行定序。

另外，无论是主租户还是备租户，在Paxos Group日志流副本中都会有LEADER和FOLLOWER两种角色。对于主租户，其业务数据是在日志流的Leader节点上写入，再同步给所有Follower节点；对于备租户，日志流的Leader节点主要负责通过日志传输服务从主租户同步日志，并将同步过来的日志再同步给Paxos Group中的Follower节点。

1.4 主租户和备租户切换

OceanBase数据库的主租户和备租户可以通过SwitchOver和Failover操作动态改变租户角色：

Switchover：在用户计划内对租户角色进行变更。执行 Switchover操作后，主租户会与对应的备租户会交换租户角色，整个过程数据不丢失RPO = 0，执行时间一般为秒级。

#将主租户切换为备租户
ALTER SYSTEM SWITCHOVER TO STANDBY TENANT = tenant_name;
#将备租户切换为主租户
ALTER SYSTEM SWITCHOVER TO PRIMARY TENANT = tenant_name;

Failover：在主租户出现无法恢复的故障时所做的切换行为。执行Failover操作后，对应的备租户角色会变换成主。同时，如果对主租户故障前一直正常同步的备租户执行Failover操作，则执行Failover操作后，一般会产生百毫秒级别的数据损失，执行时间一般为秒级。

#将备租户切换为主租户
ALTER SYSTEM ACTIVATE STANDBY TENANT = tenant_name;

Failover操作需要在操作执行完成后达到数据一致的状态，故系统会选择所有日志流的同步位点中SCN最小的值作为Failover的执行位点。执行Failover操作后，租户下的所有日志流都会统一回退到该位点。

2、GoldenDB数据库

在这里插入图片描述

GoldenDB分布式数据库除了支持同一套集群多中心的部署架构外，还支持DRSP的灾备部署方案。DRSP高可用架构包括生产库和灾备库/应急库，生产库是正常对外提供服务的GoldenDB集群；灾备库正常情况不提供服务，从生产库复制数据的GoldenDB系统，用于提供灾难、应急等场景下的紧急启动能力，代替生产库提供服务。如果所示，DRSP灾备集群运行有三种模式：

数据同步模式：元数据、GTM数据、数据节点分别从源端生产库同步到目标端灾备库，可通过配置延时时间让同步过来的数据延时应用到灾备库上。
数据恢复模式：应用、检查、修复同步过来的数据，使最终数据满足分布式一致性要求。
服务模式：启用灾备集群，对外提供服务，，提供GoldenDB系统绝大部分正常功能。

这种部署方案的优点是生产集群和灾备集群单独维护，故障互不影响。相比较异地故障切换或者灾备孤岛演练，在切换方案上更为迅速灵活。相对应的缺点就是需要单独维护两套系统，增加了运维的复杂度。

2.1 不同模式切换

1）数据同步模式

正常情况下，生产库处于服务模式，此时灾备库应当进入延时复制模式（sync模式）接入生产库。执行以下命令进入延时复制模式：

sh AllControl.sh -sync 1 -delay_time=

delay_time填写延时应用的时间，单位为秒；如果不需要延时则填0

2）数据恢复模式

当生产库发生故障或误操作时，需要切换至灾备库进行接管，此时灾备库应当先进入数据恢复模式（recovery模式）恢复数据，再切换至服务模式对外提供服务。

命令退出延时复制模式

sh AllControl.sh -stopsync 1

指定需要回放到的时刻或GTID

#指定回放时刻
sh bat_mod_relaytime.sh 1 "RELAY_TIME"
#回放所有relay log
sh bat_mod_relaytime.sh 1 ""
#指定回放的GTID

三种场景中记录下的回放时刻在回切时会作为生产库元数据同步的起始时刻

进入灾备库数据恢复模式

sh AllControl.sh -recover 1

3）数据服务模式

数据恢复完成后，通过以下步骤切换至服务模式

sh AllControl.sh -service 1

当灾备库不再需要服务时，执行命令退出服务模式

2.2 灾备库回切

当灾备库服务一段时间以后，需要将服务回切至生产库，要求生产库数据和灾备库基本一致。此时可以将生产库和灾备库角色对调，将生产库接入当前已服务的灾备库中，从灾备库同步数据。停止灾备库业务，等待生产库同步数据完成后启动生产库，由生产库提供服务。

登录生产库某一管理节点服务器，将生产库退出服务模式

sh AllControl.sh -stopservice 1

生产库集群1停服

sh start_stop_service.sh -stop_dbproxy 1

修改元数据同步起始时刻，回滚生产库集群至一致性时刻，并进行分片数据一致性校验

sh bat_mod_laststamp.sh "1" "2024-01-01 10:00:00"
其中1为集群ID，"2024-01-01 10:00:00"为元数据同步起始时刻，该时刻根据灾备库进行恢复时设置的恢复时间确定

purge生产库完成回滚且主备数据一致的分片
生产库进入延时复制模式

sh AllControl.sh -sync 1 -delay_time=0

逐步停掉灾备库上的业务，让proxy上所有事务都提交。禁用灾备库集群1，停止该集群绑定的所有proxy进程。
生产库退出复制模式并进入服务模式
灾备库退出服务模式并进入延迟复制模式

2.3 灾备演练场景回切

在灾备孤岛等演练场景下，灾备站点和生产站点孤岛隔离，演练结束后，需要将灾备站点的数据回滚到演练前的时刻。GoldenDB数据库的DRSP复制方案中提供了闪回功能，将数据闪回到灾备库恢复之后，提供服务之前的一个时刻。

快照持久化：针对灾备库，在灾备库执行服务模式起连接实例之前，将当前灾备库的快照点持久化到RDB库。为后续的闪回提供服务。
闪回：将灾备库服务模式下产生的业务恢复至快照点，方法是执行性反向sql，所以灾备库服务期间，如果有DDL，可能会失败。此时根据实际情况，看是否需要备份恢复。
备机回放检查：闪回功能是通过在主机上执行反向sql来完成回滚操作，所以备机可以以同步回放的方式进行数据同步。所以需要所有备机回放完全完成才可以下一步的purge。
purge：闪回通过反向sql实现的，所有本身的灾备库gtid_set会一直增加，所以需要通过purge操作将gtid_set恢复至快照时刻。

以上是OceanBase数据库和GoldenDB数据库延迟复制和灾备的高可用实现方案简单总结，实际实现过程更为复杂，以官方的文档材料为准。