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. Swoole从入门到入土(18)——WebSocket服务器[心跳ping]

    由于 WebSocket 是长连接,如果一定时间内没有通讯,连接可能会断开.这时候需要心跳机制,WebSocket 协议包含了 Ping 和 Pong 两个帧,可以定时发送 Ping 帧来保持长连接. ...

  2. pikachu sql inject 时间盲注

    输入框输入任何消息返回内容都是一样的 那么可以考虑插入sleep函数来观察响应时长来判断是否有注入点 输入 kobe' and sleep(3) # 发现页面缓冲3秒才响应,说明确实是注入点 通过if ...

  3. 使用paramiko模块远程连接遇到paramiko.ssh_exception.NoValidConnectionsError的解决办法

    连接时报错paramiko.ssh_exception.NoValidConnectionsError, 解决办法 首先在ubuntu终端上输入:cat /etc/ssh/ssh_config,查看端 ...

  4. 【系统选型】企业即时通讯(IM)软件调研及供应商对比评估

    企业即时通讯(IM)软件调研及供应商对比评估 1.概览 1.1 即时通讯 即时通讯(Instant messaging,简称IM)是一个终端服务,允许两人或多人使用网路即时的传递文字讯息.档案.语音与 ...

  5. Jepsen 测试框架在图数据库 Nebula Graph 中的实践

    在本篇文章中主要介绍图数据库 Nebula Graph 在 Jepsen 这块的实践. Jepsen 简介 Jepsen 是一款用于系统测试的开源软件库,致力于提高分布式数据库.队列.共识系统等的安全 ...

  6. 【Flink入门修炼】2-2 Flink State 状态

    什么是状态?状态有什么作用? 如果你来设计,对于一个流式服务,如何根据不断输入的数据计算呢? 又如何做故障恢复呢? 一.为什么要管理状态 流计算不像批计算,数据是持续流入的,而不是一个确定的数据集.在 ...

  7. Python回顾面向对象

    [一]面向过程开发和面向对象开发 [1]面向过程包括函数和面条 包括面条版本一条线从头穿到尾 学习函数后开始对程序进行分模块,分功能开发 学习模块化开发,我们就可以对我们的功能进行分类开发 建一个功能 ...

  8. 第143篇:手写vue-router,实现router-view

    好家伙,   今天来手写我们的老伙计vue-router,   1.替换router 新开一个项目,并使用我们手写的router   2.大致结构 let Vue; // 保存vue的构造函数 cla ...

  9. PowerShell alias - cmd中设置别名 快捷的执行命令

    Step. 1: 发现需求 最近学nest.js发现,都是用命令创建工程文件,然后教程里面都是用的快捷命令 比如 pd = pnpm run dev pb = pnpm run build 但是我这里 ...

  10. pod的拉取和重启策略

    在Kubernetes中,Pod的拉取策略和重启策略可以通过YAML配置文件来定义. Pod的拉取策略 Pod的拉取策略指的是Kubernetes在创建或重启Pod时,如何获取Pod所需的容器镜像.这 ...