KingbaseES集群运维案例之---主备库failover后auto-recovery机制

案例说明:

KingbaseES集群,在备库数据库服务down后,可以实现节点数据库服务的自动恢复;在集群触发failover的主备切换后,实现原主库自动被recovery为备库,重新加入到集群。对于Kingbase V8R3和V8R6的实现机制不同,本次案例将描述两种版本的实现机制。

适用版本:

KingbaseES V8R3/R6

一、KingbaseES V8R3实现机制

集群架构:

TEST=# show pool_nodes;
node_id | hostname | port | status | lb_weight | role | select_cnt | load_balance_node | replication_de
lay
---------+---------------+-------+--------+-----------+---------+------------+-------------------+---------------
----
0 | 192.168.1.101 | 54321 | up | 0.333333 | primary | 0 | false | 0
1 | 192.168.1.102 | 54321 | up | 0.333333 | standby | 0 | false | 0
2 | 192.168.1.103 | 54321 | up | 0.333333 | standby | 0 | true | 0
(3 rows)

1、备库数据库服务自动恢复机制

1)备库节点配置

如下所示,集群在部署完成后,会创建network_rewind.sh脚本的crond定时任务。通过此脚本检测数据库服务状态,并恢复。

[kingbase@node102 bin]$ cat /etc/cron.d/KINGBASECRON
*/1 * * * * kingbase /home/kingbase/cluster/HAR3/db/bin/network_rewind.sh
*/1 * * * * root /home/kingbase/cluster/HAR3/kingbasecluster/bin/restartcluster.sh

2)kingbasecluster检测数据库服务

如下所示,kingbasecluster检测节点的数据库服务状态,并在cluster.log中显示

2023-06-16 11:00:13: pid 10530: LOG:  failover command lock request from local kingbasecluster node received on IPC interface is forwarded to master watchdog node "192.168.1.102:9999 Linux node102"
2023-06-16 11:00:13: pid 10530: DETAIL: waiting for the reply...
2023-06-16 11:00:13: pid 10487: LOG: starting fail back. reconnect host 192.168.1.102(54321)
......
2023-06-16 11:00:13: pid 10487: LOG: failback done. reconnect host 192.168.1.102(54321)

3)备库节点执行recovery恢复数据库服务

如下所示,备库通过调用sys_rewind,执行备库数据库服务的恢复,在recovery_log中日志记录。

if recover node up, let it down , for rewind
2023-06-16 11:00:04 sys_rewind...
sys_rewind --target-data=/home/kingbase/cluster/HAR3/db/data --source-server="host=192.168.1.101 port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST"
datadir_source = /home/kingbase/cluster/HAR3/db/data
rewinding from last common checkpoint at 1/69000028 on timeline 13
find last common checkpoint start time from 2023-06-16 11:00:04.453168 CST to 2023-06-16 11:00:04.499843 CST, in "0.046675" seconds.
reading source file list
reading target file list
reading WAL in target
Rewind datadir file from source
Get archive xlog list from source
Rewind archive log from source
update the control file: minRecoveryPoint is '1/69022120', minRecoveryPointTLI is '13', and database state is 'in archive recovery'
rewind start wal location 1/69000028 (file 0000000D0000000100000069), end wal location 1/69022120 (file 0000000D0000000100000069). time from 2023-06-16 11:00:05.453168 CST to 2023-06-16 11:00:06.230588 CST, in "1.777420" seconds.
Done!

2、failover切换后原主库恢复

1)集群配置

如下所示,参数AUTO_PRIMARY_RECOVERY定义了在执行failover切换后,原主库是否自动恢复为备库并加入到集群;AUTO_PRIMARY_RECOVERY=0(默认)将不执行自动恢复,人工干预;AUTO_PRIMARY_RECOVERY=1,执行自动恢复,将原主库恢复为备库加入到集群。

[kingbase@node101 bin]$ cat ../etc/HAmodule.conf |grep -i recovery
#whether to turn on automatic recovery,0->off,1->on.example:AUTO_PRIMARY_RECOVERY="1"
AUTO_PRIMARY_RECOVERY=0

2)配置主库failover自动恢复

如下所示,配置AUTO_PRIMARY_RECOVERY=1,实现failover切换后,原主库自动recovery为备库加入集群。

[kingbase@node101 HAR3]$ cat db/etc/HAmodule.conf |grep -i auto_primary
#whether to turn on automatic recovery,0->off,1->on.example:AUTO_PRIMARY_RECOVERY="1"
AUTO_PRIMARY_RECOVERY=1

主备切换后cluster.log日志:

kingbasecluster进程检测到原主库数据库服务状态,执行recovery。

2023-06-16 13:57:12: pid 21372: LOG:  starting fail back. reconnect host 192.168.1.101(54321)
2023-06-16 13:57:12: pid 21372: LOG: Node 1 is not down (status: 2)
2023-06-16 13:57:12: pid 21411: LOG: received the failover command lock request from remote kingbasecluster node "192.168.1.102:9999 Linux node102"
........
2023-06-16 13:57:12: pid 21372: LOG: failback done. reconnect host 192.168.1.101(54321)

原主库recovery.log:

如下所示,原主库执行sys_rewind后,被恢复为备库加入到集群。

2023-06-16 13:57:04 sys_rewind...
sys_rewind --target-data=/home/kingbase/cluster/HAR3/db/data --source-server="host=192.168.1.102 port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST"
datadir_source = /home/kingbase/cluster/HAR3/db/data
pid file found but it seems bogus. Trying to start rewind anyway...
rewinding from last common checkpoint at 1/69024B90 on timeline 13
find last common checkpoint start time from 2023-06-16 13:57:04.593305 CST to 2023-06-16 13:57:04.616058 CST, in "0.022753" seconds.
reading source file list
reading target file list
reading WAL in target
Rewind datadir file from source
Get archive xlog list from source
Rewind archive log from source
update the control file: minRecoveryPoint is '1/6A025190', minRecoveryPointTLI is '14', and database state is 'in archive recovery'
rewind start wal location 1/69024B58 (file 0000000D0000000100000069), end wal location 1/6A025190 (file 0000000E000000010000006A). time from 2023-06-16 13:57:05.593305 CST to 2023-06-16 13:57:06.544920 CST, in "1.951615" seconds.
Done!

二、KingbaseES V8R6实现机制

集群架构:

ID | Name  | Role    | Status    | Upstream | repmgrd | PID   | Paused? | Upstream last seen
----+-------+---------+-----------+----------+---------+-------+---------+--------------------
1 | node1 | primary | * running | | running | 16734 | no | n/a
2 | node2 | standby | running | node1 | running | 23606 | no | 1 second(s) ago

集群参数配置:

[kingbase@node101 bin]$ cat ../etc/repmgr.conf |grep -i recovery
recovery='manual' 节点故障自动恢复,automatic、standby、manual, 默认值为standby。
manual,关闭自动恢复,故障节点无论是主机还是备机, 都不进行自动恢复;
standby,故障节点是备机才自动恢复;
automatic,所有故障节点都自动恢复。

1、备库数据库服务自动恢复机制

1)配置集群参数

[kingbase@node101 bin]$ cat ../etc/repmgr.conf |grep -i recovery
recovery='standby'
可以配置recovery参数为standby或automatic。

2)备库数据库服务down后恢复

如下所示,主库通过sys_stat_replication获取不到备库的节点信息后,将通过远程调用kbha进程将备库数据库服务拉起,并加入到集群。

[2023-06-16 14:40:58] [DEBUG] child node: 2; attached: no
.......
[2023-06-16 14:41:03] [NOTICE] [thread pid:17949] Now, the primary host ip: 192.168.1.101
[2023-06-16 14:41:03] [DEBUG] test_ssh_connection(): executing ssh -o Batchmode=yes -q -o ConnectTimeout=10 -o StrictHostKeyChecking=no -o ServerAliveInterval=2 -o ServerAliveCountMax=5 -p 22 192.168.1.102 /bin/true 2>/dev/null
[2023-06-16 14:41:03] [INFO] [thread pid:17949] ES connection to host "192.168.1.102" succeeded, ready to do auto-recovery
[2023-06-16 14:41:03] [INFO] node "node2" (ID: 2, HOST: 192.168.1.102) auto-recovery: START DATABASE
[2023-06-16 14:41:03] [DEBUG] remote_command():
ssh -o Batchmode=yes -q -o ConnectTimeout=10 -o StrictHostKeyChecking=no -o ServerAliveInterval=2 -o ServerAliveCountMax=5 -p 22 192.168.1.102 /home/kingbase/cluster/R6HA/ha7/kingbase/kingbase/bin/kbha -A startdb
[2023-06-16 14:41:02] [NOTICE] begin to start server at 2023-06-16 14:41:02.000501
[2023-06-16 14:41:02] [NOTICE] starting server using "/home/kingbase/cluster/R6HA/ha7/kingbase/kingbase/bin/repmgr node service --action start 2>/dev/null"
[2023-06-16 14:41:02] [INFO] starting database ...
.......
[2023-06-16 14:41:03] [NOTICE] [thread pid:17949] node "node2" (ID: 2) auto-recovery success

2、failover切换后原主库恢复

1)配置集群参数

[kingbase@node101 bin]$ cat ../etc/repmgr.conf |grep -i recovery
recovery=’automatic'

2)failover切换后原主库recovery

如下所示,在完成failover切换后,如果recovery=’automatic',则对原主库执行auto-recovery,将原主库恢复为备库并加入到集群,以下是新主库hamgr.log日志信息。

[2023-06-16 15:08:45] [INFO] node "node1" (ID: 1, HOST: 192.168.1.101) auto-recovery: NODE REJOIN
..........
[NOTICE] begin to start server at 2023-06-16 15:08:47.668913
[NOTICE] starting server using "/home/kingbase/cluster/R6HA/ha7/kingbase/kingbase/bin/sys_ctl -w -t 90 -D '/data/kingbase/hac7/data' -l /home/kingbase/cluster/R6HA/ha7/kingbase/kingbase/bin/logfile start"
[NOTICE] start server finish at 2023-06-16 15:08:47.779029**
[NOTICE] NODE REJOIN successful
[DETAIL] node 1 is now attached to node 2
[2023-06-16 15:08:47] [NOTICE] kbha: node (ID: 1) rejoin success.

三、总结

对于集群主备库数据库服务的auto-recovery,可以根据业务需求及数据安全性角度考虑是否启用。

 1、对于KingbaseES V8R3集群,可以在备库节点关闭rewind的crond计划任务,禁止备库数据库服务的auto-recovery。如下所示:
[kingbase@node101 bin]$ cat /etc/cron.d/KINGBASECRON
##*/1 * * * * kingbase /home/kingbase/cluster/HAR3/db/bin/network_rewind.sh 2、可以配置AUTO_PRIMARY_RECOVERY参数,启用或关闭主库的failover后自动恢复,对于数据安全性高的,可以禁用auto-recovery,通过对业务数据检验安全后,再手工恢复原主库。
3、对于KingbaseES V8R6版本,则根据业务需求及数据安全性要求,配置recovery参数即可。

KingbaseES集群运维案例之---主备库failover后auto-recovery机制的更多相关文章

  1. KingbaseES V8R3集群运维案例之---主库系统down failover切换过程分析

    ​ 案例说明: KingbaseES V8R3集群failover时两个cluster都会触发,但只有一个cluster会调用脚本去执行真正的切换流程,另一个有对应的打印,但不会调用脚本,只是走相关的 ...

  2. KingbaseES V8R3集群运维案例之---用户自定义表空间管理

    ​案例说明: KingbaseES 数据库支持用户自定义表空间的创建,并建议表空间的文件存储路径配置到数据库的data目录之外.本案例复现了,当用户自定义表空间存储路径配置到data下时,出现的故障问 ...

  3. KingbaseES V8R3集群运维案例之---kingbase_monitor.sh启动”two master“案例

    案例说明: KingbaseES V8R3集群,执行kingbase_monitor.sh启动集群,出现"two master"节点的故障,启动集群失败:通过手工sys_ctl启动 ...

  4. KingbaseES V8R6集群运维案例之---repmgr standby promote应用案例

    案例说明: 在容灾环境中,跨区域部署的异地备节点不会自主提升为主节点,在主节点发生故障或者人为需要切换时需要手动执行切换操作.若主节点已经失效,希望将异地备机提升为主节点. $bin/repmgr s ...

  5. KingbaseES V8R3集群运维案例之---cluster.log ERROR: md5 authentication failed

    案例说明: 在KingbaseES V8R3集群的cluster.log日志中,经常会出现"ERROR: md5 authentication failed:DETAIL: password ...

  6. PB 级大规模 Elasticsearch 集群运维与调优实践

    PB 级大规模 Elasticsearch 集群运维与调优实践 https://mp.weixin.qq.com/s/PDyHT9IuRij20JBgbPTjFA | 导语 腾讯云 Elasticse ...

  7. 阿里巴巴大规模神龙裸金属 Kubernetes 集群运维实践

    作者 | 姚捷(喽哥)阿里云容器平台集群管理高级技术专家 本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击即可完成下载. 导读:值得阿里巴巴技术人骄傲的是 2019 ...

  8. 集群运维ansible

    ssh免密登录 集群运维 生成秘钥,一路enter cd ~/.ssh/ ssh-keygen -t rsa 讲id_rsa.pub文件追加到授权的key文件中 cat ~/.ssh/id_rsa.p ...

  9. KingbaseES集群管理维护案例之---备库checkpoint分析

    ​ 数据库异常关闭时,数据库关闭时来不及或者没机会做checkpoint,则需要从上一个一致性检查的开始恢复.KingbaseES备机checkpoint是不能产生checkpoint WAL日志条目 ...

  10. 云计算之路-阿里云上:RDS数据库连接数过万引发故障,主备库切换后恢复正常

    非常抱歉!今天 12:03-12:52 ,由于数据库连接数异常突增超过1万,达到了阿里云RDS的最大连接数限制,影响了全站的正常访问.由此给您带来麻烦,请您谅解. 在发现数据库连接数突增的问题后,我们 ...

随机推荐

  1. java使用Timer定时器在指定时间执行程序

    下面是一个利用Timer定时器在每天指定时间执行批处理程序的例子. 有关 java.util.Timer 详细知识请参考API. 值得注意的一点是Timer是单线程顺序执行多个任务的. package ...

  2. 双哈希_Birthday_Cake

    Birthday Cake 思路:找到每个串的公共前后缀,统计公共前后缀之间的字符串的hash值,并判断所给n个串中是否存在符合条件的串 eg:abbddab 对于该串,我们不难发现,公共前后缀是ab ...

  3. 【Android 逆向】【ARM汇编】 函数的栈帧

    1. 函数的调用约定 ARM32 参数1-4 放入r0-r3 剩下的入栈,函数返回值放入r0 ARM64 参数1-8 放入X0-X7 剩下的入栈,函数返回值放入X0 (浮点数是放入 Dn 或 Sn) ...

  4. MySQL的随机排序(random orderby)

    MySQL的随机排序(random orderby)是指在查询数据库时,将结果集以随机的方式排列.这种排序方式可以用于有趣的应用场景,例如实现随机音乐播放.广告推荐等. 要实现MySQL的随机排序,可 ...

  5. Apple设备屏幕尺寸和方向

    表格中包括了各种型号的iPad.iPhone.以及iPod touch等设备的详细信息,涵盖了从iPad Pro到各代iPhone和iPod touch的多个型号. 这些信息可用于开发应用程序时优化界 ...

  6. 面向对象之封装,类的相关操作,私有成员删除,构造方法__init__---day20

    1.面向对象之封装 # ### 面向对象oop -封装 """ 类中封装: 成员属性 成员方法 封装等级: 1.公有:公有成员既能够在类外调用,也可在类内调用 2.私有: ...

  7. offline RL | 读读 Decision Transformer

    论文标题:Decision Transformer: Reinforcement Learning via Sequence Modeling,NeurIPS 2021,6 6 7 9 poster( ...

  8. Spring-Cloud集成redis-cluster

    前言 系统之前接入的是单点redis,为了条系统高可用能力,特增加集成redis-cluster集群的步骤 依赖库引入 <dependency> <groupId>org.sp ...

  9. 【Azure 服务总线】Azure门户获取ARM模板,修改Service Bus的TLS版本

    问题描述 在Azure中创建Sverice Bus服务后,如果想修改服务的TLS版本,是否有办法呢? 问题解答 通过Service Bus的ARM模板,修改属性值中的 minimumTlsVersio ...

  10. 【Azure 事件中心】关闭或开启Azure Event Hub SDK中的日志输出

    问题描述 使用Azure Event Hub的Java SDK 作为消费端消费消息,集成在项目中后,发现大量日志产生,并且都是Debug 级别日志,如何来关闭这部分日志输出呢? import com. ...