KingbaseES 与Oracle主备集群Failover切换故障自动恢复机制

为保证业务的访问的连续性，对于主备复制架构的数据库高可用集群，最重要的一个特性是，当主库节点出现故障时，能实现资源的切换。在主库数据库不能响应业务访问时，集群自动选择其中一个备库节点提升为主库，实现主备切换。
KingbaseES主备流复制和Oracle DataGuard主备复制高可用集群都支持主备的failover切换，在一些无人值守的生产环境，对于主备流复制架构，当主库数据库服务down后，需要首先能触发主备的failover切换，其次对于原主库可以实现自动恢复为新的备库加入到集群，保证集群架构的稳定性和业务数据的安全。
本文对两种数据库主备复制架构集群的failover切换的配置及其原理进行分析对比，见证国产数据库高可用架构的发展。

一、KingbaseES主备复制Failover切换机制

图1-1 KingbaseES主备流复制架构图

1、KingbaseES主备复制高可用机制

1. 读写分离集群的基础架构是主备流复制，主备库之间通过wal日志的传输和应用，保证数据的一致性。
2. 通过repmgr工具对主备节点状态监控及主备故障切换等。
3. KingbaseES提供后台数据库服务，repmgrd为repmgr后台进程。
4. 主库repmgrd进程监控自身数据库服务状态，并通过sys_stat_replication获取备库节点状态。备库repmgrd监控自身及主库数据库服务状态。
5. KBHA提供repmgrd进程的监控和故障恢复。

2、KingbaseES主备复制集群failover切换机制
如下所示，KingbaseES主备复制集群支持手工或自动failover主备切换，参数配置：

[kingbase@node201 bin]$ cat ../etc/repmgr.conf |grep failover
failover='automatic‘ |’manual’
Automatic：   支持主备之间failover自动切换。
Manual：      不支持主备之间failover自动切换，需要人工参与切换。

3、KingbaseES主备复制集群failover切换恢复机制
如下所示，KingbaseES主备复制集群在failover切换后，可以人工参与恢复原主库或自动恢复（auto-recovery），参数配置：

[kingbase@node201 bin]$ cat ../etc/repmgr.conf |grep recovery
recovery=‘manual’| ‘standby’ |‘automatic’
Automatic： 支持备库数据库服务down后auto-recovery，支持failover切换后，自动恢复原主库作为新备库加入到集群。
Standby：   支持备库数据库服务down后auto-recovery。
Manual：    节点数据库服务down后需要人工参与恢复。

二、Oracle主备复制Failover切换机制

图2-1 Oracle DataGuard架构图

1、Oracle DataGuard运行机制

• Data Gurad 通过redo日志同步机制保证主备库之间数据同步，同步可以是同步或者异步模式，DataGurad 通过冗余数据来提供数据保护。
• 主库（Primary）处于Open 状态对外提供读写服务，备库（Standby）处于恢复状态，对于Active Standby还可以提供只读服务。
• 主库在事务处理过程中，操作被记录在联机日志（redo log）和归档日志中（Archive log），这些日志通过网络传递给Standby。这个日志会在Standby上重演，从而实现Primary和Standby的数据同步。

2、DataGuard手工failover操作步骤
默认，DataGuard不支持failover启动切换，如下所示，手工执行failover主备切换：

1）停止目标备库日志应用
SQL> alter database recover managed standby database cancel;

2）完成备库日志应用
alter database recover managed standby database finish;

3）检查备库状态
状态为TO PRIMARY或SESSIONS ACTIVE均可切换，SESSIONS ACTIVE说明还有活跃会话
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY

4）将备库切为主库
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

5）OPEN新主库
ALTER DATABASE OPEN;

6）检查新主库状态
SQL> select name,open_mode,database_role from v$database;
NAME OPEN_MODE DATABASE_ROLE
--------- -------------------- ----------------
MYTEST READ WRITE PRIMARY

3、Failover切换后手工恢复主备架构
这里介绍Failover后利用闪回恢复主备同步的方法，要求原主库（Failover后的备库）闪回功能必须打开并且闪回日志还在。利用DG Broker操作，其实原理是一样的，只是Oracle帮你做了。
假设当前failover已完成，新主库已打开。

在新主库上执行：
select to_char(standby_became_primary_scn) from v$database;

在原主库上，也就是现在的备库执行：

1. startup mount flashback database to scn 9978113;       --这个值为在新主库上查询到的SCN值
2. alter database convert to physical standby;
3. shutdown immediate
4. startup
5. alter database recover managed standby database using current logfile disconnect from session parallel 4;

4、 配置DataGuard的自动恢复（FSFO)

对于DataGuard启动FSFO，需要启动或配置以下相关服务：

1) Data Guard Broker

图2-4 Oracle DataGuard Broker架构图

默认Oracle DataGuard不支持failover主备自动切换，需要结合DG broker执行failover的自动切换。
Broker 是一个Data Guard管理实用程序，用于维护有关主数据库及其备用数据库的状态信息。 它自动设置与 Data Guard 相关的数据库初始化参数（如实例启动和角色转换)、启动备用数据库的应用服务，并且自动执行与维护 Data Guard 配置相关的许多管理任务。

2) Observer服务
Observer是一个OCI（Oracle Call Interface）客户端组件，通常运行在独立服务器并监视主库可用性。
顾名思义，Observer可以观察主备库之间的活动，决定是否进行FSFO，因此我们需要在连接性最高的服务器上安装Observer。FSFO可能会导致错误的故障转移，即使主库正在运行并且可以在本地访问，也可能会发生FSFO；如果客户端无法访问主库，也可能不发生FSFO。

图2-5 Observer应用架构图

启动Observer：

[oracle@localhost oradata]$ dgmgrl
...
DGMGRL> connect sys/oracle@testdb
Connected.
DGMGRL> start observer;
Observer started

3) Fast-Start Fail Over（FSFO）
FSFO允许代理在主库故障的情况下自动故障转移到先前选择的备库，无需手动执行任何步骤，以便快速可靠地恢复业务。FSFO只能在代理配置中使用，并且只能通过DGMGRL或OEM进行配置。
FSFO支持在最高可用性与最高性能模式下使用。最大可用性模式保证不会丢失任何数据，最高性能模式可保证丢失的数据量不超过FastStartFailoverLagLimit属性指定的数据量（单位为秒）。

图2-6 FSFO应用架构图

如下所示，FSFO配置：

show configuration
Configuration Name:
FSF Enabled: NO
Protection Mode: MaxAvailability
Databases: db1_a - Primary database   db1_b - Physical standby database
Fast-Start Failover: ENABLED
Current status for "FSF":ENABLED

设置故障转移目标：

只能为当前主库设置一个目标转移备库，若只有一个备库，此步骤可忽略。若要修改目标转移备库，需要先禁用FSFO，改完后再启用。
DGMGRL> EDIT DATABASE TESTDB SET PROPERTY FASTSTARTFAILOVERTARGET=STD_TESTDB;
Property "faststartfailovertarget" updated
 DGMGRL> EDIT DATABASE STD_TESTDB SET PROPERTY FASTSTARTFAILOVERTARGET=TESTDB;
Property "faststartfailovertarget" updated

三、KingbaseES Failover切换后故障自动恢复机制

1、KingbaseES主备复制集群failover切换后原主库自动恢复机制

在failover切换后，新主库开启auto-recovery恢复原主库作为备库加入到集群，通过sys_rewind工具来实现原主库的恢复。
sys_rewind检查源和目标集群的时间线历史以确定它们的分歧点，并在目标集群的sys_wal目录中找到WAL，一直到达分歧点。分歧点可以在目标时间线、源时间线或它们的共同祖先上找到。
在典型的故障转移场景中，目标集群在产生分歧后很快被关闭，这不是问题，但如果目标集群在生生分歧后运行很长时间，它的旧WAL文件可能不再存在。在这种情况下，您可以手动将它们从WAL归档目录复制到sys_wal目录，或者使用 -c 选项运行sys_rewind以自动从WAL归档中目录中检索它们。
sys_rewind 的使用不限于故障转移，例如，可以提升备用服务器主库，运行一些写入事务，然后重新回滚再次成为备用服务器。

2、sys_rewind执行过程分析

如下图所示，sys_rewind通过源库和目标库的timeline history文件对比获取分叉点：

1） 读取目标和源库控制文件对比system_id、version等
datadir_source = /data/kingbase/r6ha/data
sys_rewind: fetched file "global/sys_control", length 8192
sys_rewind: fetched file "sys_wal/0000001C.history", length 1174

2） 读取目标和源库timeline的history文件寻找分叉点（diverged）
sys_rewind: Source timeline history:
sys_rewind: Target timeline history:
sys_rewind: 1: 0/0 - 0/690000A0
sys_rewind: 2: 0/690000A0 - 0/6A0000A0
.......
sys_rewind: 23: 3/320000A0 - 4/4B0000A0
sys_rewind: 24: 4/4B0000A0 - 4/4D0000A0
sys_rewind: 25: 4/4D0000A0 - 4/51001D00
sys_rewind: 26: 4/51001D00 - 4/520000A0
sys_rewind: 27: 4/520000A0 - 4/630000A0
sys_rewind: 29: 4/630000A0 - 0/0
sys_rewind: servers diverged at WAL location 4/540000A0 on timeline 27
sys_rewind: for record '27/4/54000028', remote hash is '0'
sys_rewind: for record '27/4/53000C20', local hash is '3038469505' and remote hash is '3038469505'
sys_rewind: rewinding from last common checkpoint at 4/53000C20 on timeline 27
sys_rewind: find last common checkpoint start time from 2022-09-13 14:18:54.005053 CST to 2022-09-13 14:18:54.123611 CST, in "0.118558" seconds.

3）拷贝源库数据文件和变化的页块到目标库
sys_rewind: backup_label.old (COPY)
sys_rewind: base/1/1247_fsm (COPY)
sys_rewind: base/1/1247_vm (COPY)
.......
sys_rewind: received chunk for file "base/32955/189163", offset 4325376, size 32768
sys_rewind: received chunk for file "base/32955/189163", offset 4358144, size 32768
sys_rewind: received chunk for file "base/32955/189163", offset 4390912, size 32768
sys_rewind: received chunk for file "base/32955/2619", offset 262144, size 32768

4）应用checkpoint后wal日志并更新目标库controlfile
sys_rewind: update the control file: minRecoveryPoint is '4/56E13200', minRecoveryPointTLI is '28', and database state is 'in archive recovery'
sys_rewind: we will remove the dir '/data/kingbase/r6ha/data/sys_replslot/repmgr_slot_2.rewind' and all the file/dir in it.
sys_rewind: rewind start wal location 4/53000BF0 (file 0000001B0000000400000053), end wal location 4/56E13200 (file 0000001C0000000400000056). time from 2022-09-13 14:18:54.005053 CST to 2022-09-13 14:19:05.426387 CST, in "11.421334" seconds.
sys_rewind: Done!

3、KingbaseES主备复制集群failover切换后主库自动恢复过程
如下所示，日志记录failover切换后调用sys_rewind将原主库恢复为新备库过程：

---将原主库恢复为新的备库加入到集群（auto-recovery），调用sys_rewind。

[2024-05-16 11:33:44] [NOTICE] executing repmgr command "/home/kingbase/cluster/R6C8/HAC8/kingbase/bin/repmgr --dbname="host=192.168.1.202 dbname=esrep user=esrep port=54321" node rejoin --force-rewind --upstream-node-id 2"
[NOTICE] rejoin target is node "node2" (ID: 2)
[DEBUG] connecting to: "user=esrep connect_time
......

---执行sys_rewind

[NOTICE] executing sys_rewind
[DETAIL] sys_rewind command is "/home/kingbase/cluster/R6C8/HAC8/kingbase/bin/sys_rewind -D '/home/kingbase/cluster/R6C8/HAC8/kingbase/data' --source-server='host=192.168.1.202 user=esrep dbname=esrep port=54321 connect_timeout=10 keepalives=1 keepalives_idle=10 keepalives_interval=1 keepalives_count=3'"
sys_rewind: servers diverged at WAL location 2/260000A0 on timeline 35
sys_rewind: no rewind required
sys_rewind: status check: restore all the backup temp file, Done!
[NOTICE] 0 files copied to /home/kingbase/cluster/R6C8/HAC8/kingbase/data
[DEBUG] deleting slot directory "/home/kingbase/cluster/R6C8/HAC8/kingbase/data/sys_replslot/repmgr_slot_2"
[INFO] creating replication slot as user "esrep"
[DEBUG] CreateSlotBySQL(): creating slot "repmgr_slot_1" on upstream
[NOTICE] setting node 1's upstream to node 2
[WARNING] unable to ping "host=192.168.1.201 user=esrep dbname=esrep port=54321 connect_timeout=10 keepalives=1 keepalives_idle=10 keepalives_interval=1 keepalives_count=3 tcp_user_timeout=9000"
[DETAIL] KCIping() returned "KCIPING_NO_RESPONSE"
[NOTICE] begin to start server at 2024-05-16 11:33:44.889640
[NOTICE] starting server using "/home/kingbase/cluster/R6C8/HAC8/kingbase/bin/sys_ctl  -w -t 90 -D '/home/kingbase/cluster/R6C8/HAC8/kingbase/data' -l /home/kingbase/cluster/R6C8/HAC8/kingbase/bin/logfile start"
[NOTICE] start server finish at 2024-05-16 11:33:44.995853

---原主库被恢复为新备库加入集群成功。

[NOTICE] NODE REJOIN successful
[DETAIL] node 1 is now attached to node 2
[2024-05-16 11:33:45] [NOTICE] kbha: node (ID: 1) rejoin success.

[2024-05-16 11:33:45] [DEBUG] DoRemoteCommand(): no output returned
[2024-05-16 11:33:45] [NOTICE] [thread pid:11226] node "node1" (ID: 1) auto-recovery success

四、Oracle Failover切换故障自动恢复机制

1、FSFO故障自动恢复机制

如下所示，FSFO故障自动恢复机制：

1. Data Guard Broker：用于维护有关主数据库及其备用数据库的状态信息，并且自动执行与维护 Data Guard 配置相关的许多管理任务。
2. Observer：Observer可以观察主备库之间的活动，决定是否进行FSFO。主库与 Observer和目标备库 失联时间均超过FastStartFailoverThreshold
   属性配置阈值（单位为秒），将触发FSFO。
3. 闪回数据库(flashback database）：配置FastStartFailoverAutoReinstate为true，当failover完成后，启动数据库时，
   会自动的执行Reinstate database，把原来的主数据库变成备库，并与新主库进行同步。

2、Flashback Database

   1. restore the entire database to a specific point-in-time, using Oracle-optimized flashback logs, 
rather than via backups and forward recovery.
   2. FLASHBACK日志用于跟踪用户对表中数据的修改。当启用FLASHBACK日志时，在数据库的快速恢复区中将产生FLASHBACK日志文件。
从这一时刻起，数据库中数据的变化将被记录在这些日志文件中。当关闭FLASHBACK日志，这些日志文件将被自动删除。
   3. FLASHBACK日志产生的过程如下图所示。当数据库中有事务发生是，在SGA的重做日志缓存区中将产生重做日志，
然后在数据库缓冲区缓存中将产生脏缓冲区。当事务修改数据库高速缓存中的缓冲区时，这个缓冲区中的内容将首先被拷贝到FLASHBACK缓冲区中。
这样在数据库缓冲区缓存中将保留事务修改之后的数据，而在FLASHBACK缓冲区中则保留修改之前的数据。FLASHBACK缓冲区是共享池的一部分，
它的大小可以通过查询动态性能视图V$SGASTAT获得。实例中的RVWR后台进程将把FLASHBACK缓冲区中的数据写入FLASHBACK日志文件。
通过这样的方法，就可以把数据库中任何一行数据的连续变化保存在FLASHBACK日志文件中，利用数据库的FLASHBACK，就能够得到一行数据
在过去某个时刻的样子。
   4. Flashback Database是一个集成在 Oracle 数据库中的持续数据保护 (CDP) 解决方案。它使用名为闪回日志的磁盘数据结构，
提供一个将数据库快速恢复到之前时间点或 SCN 的方法。数据库闪回比传统的时间点或基于 SCN 的恢复速度更快、
结合更完美（一条简单的 DDL 语句）。FSFO 将闪回数据库用作将故障主数据库恢复为备用数据库流程的一部分。

图4-2 Oracle flashbackup database架构图

3、设置原主库自动恢复数据库属性

如下所示，配置FSFO后原主库自动恢复：

1. 当observer与指定的备数据库与主数据库失去连接的时间超过FastStartFailoverThreshold后，observer就会启动fast-start failover 到备数据库。
2.  如果配置了FastStartFailoverPmyShutdown为true，此时原来的主数据库将会自动的shutdown。
3.  如果配置FastStartFailoverAutoReinstate为true，当failover完成后，启动数据库时，会自动的执行Reinstate database，
把原来的主数据库变成备库，并与新主库进行同步。
    DGMGRL> EDIT CONFIGURATION SET PROPERTY FASTSTARTFAILOVERAUTOREINSTATE=TRUE;
    Property "faststartfailoverautoreinstate" updated

五、总结
如下图所示，KingbaseES和Oracle主备复制架构对比总结：