KingbaseES V8R3集群运维案例之---failover切换后新主库启动过程
案例说明：
KingbaseES V8R3集群failover切换后，在生产环境中，新主库启动过程中可能会有业务访问，出现‘系统只读’的问题。如下图所示：
适用版本：
KingbaseES V8R3
一、问题分析
1、如下所示，failover切换过程：
1）在master节点执行failover_stream.sh脚本执行failover切换。
2）ping 网关地址测试网络的连通性，如果成功执行下一步，如果失败，终止切换。
3）通过ssh连接原主库停止数据库服务和卸载vip地址。
4）将vip地址加载到新主库节点并执行 arping广播测试vip地址。
5）测试当前新主库的数据库服务是否正常，通过执行‘select 3333’查询。
6）如果当前新主库数据库服务查询正常，执行备库promote为主库。
7）promote完成后，通过‘select 3333’测试当前新主库数据库服务是否正常。
8）如果数据库服务正常，在kingbase.conf中将流复制修改为‘async’并reload conf。
9）对当前新主库执行checkpoint，checkpoint'完成后执行‘select 3333’测试数据库服务是否正常。
10）数据库服务正常，failover切换完成。
-----------------2023-09-21 11:50:54 failover beging---------------------------------------
----failover-stats is %H = hostname of the new master node [192.168.1.202], %P = old primary node id [0], %d = node id[0], %h = host name [192.168.1.201], %O = old primary host[192.168.1.201] %m = new master node id [1], %M = old master node id [0], %D = database cluster path [/home/kingbase/cluster/R3HA/db/data].
----ping trust ip
ping trust ip 192.168.1.1 success
----determine whether the faulty db is master or standby
master down, let 192.168.1.202 become new primary.....
2023-09-21 11:50:56 del old primary VIP on 192.168.1.201
ssh connect host:192.168.1.201 success, will stop old primary db and del the vip
stop the old primary db
DEL VIP NOW AT 2023-09-21 11:50:57 ON enp0s3
sys_ctl: PID file "/home/kingbase/cluster/R3HA/db/data/kingbase.pid" does not exist
Is server running?
execute: [/sbin/ip addr del 192.168.1.10/24 dev enp0s3]
Oprate del ip cmd end.
2023-09-21 11:50:57 add VIP on 192.168.1.202
ADD VIP NOW AT 2023-09-21 11:50:58 ON enp0s3
execute: [/sbin/ip addr add 192.168.1.10/24 dev enp0s3 label enp0s3:2]
execute: /home/kingbase/cluster/R3HA/db/bin/arping -U 192.168.1.10 -I enp0s3 -w 1
Success to send 1 packets
2023-09-21 11:50:58 promote begin...let 192.168.1.202 become master
check db if is alive
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2023-09-21 11:50:58 kingbase is ok , to prepare execute promote
execute promote
server promoting
check db if is alive after promote
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2023-09-21 11:50:58 after execute promote , kingbase status is ok.
after execute promote, kingbase is ok.
2023-09-21 11:50:58 sync to async
ALTER SYSTEM
sys_reload_conf
-----------------
t
(1 row)
2023-09-21 11:50:58 make checkpoint
check the db to see if it is alive
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2023-09-21 11:50:59 kingbase is ok , to prepare execute checkpoint
execute checkpoint
CHECKPOINT
check the db to see if it is alive after execute checkpoint
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2023-09-21 11:50:59 after execute checkpoint, kingbase is ok.
after execute checkpoint, kingbase is ok.
-----------------2023-09-21 11:50:59 failover end---------------------------------------
如下所示，在没有业务压力的情况下，新主库在promote后，数据库服务启动快速完成：
2、生产环境下failover
1）如下failover.log日志所示，failover后在‘2023-09-19 15:12:02'完成checkpoint，测试数据库查询访问ok：
2）查看新主库sys_log
如下图所示，在’2023-09-19 15:12:01'出现应用访问数据库，出现只读故障；因为vip在数据库服务启动正常前被加载到新主库节点，用户可以通过vip连接新主库进行访问，但是此时数据服务还未启动完成，无法执行读写操作。
如下图所示，数据库服务在‘2023-09-19 15:12:36’启动完成，可以进行读写操作：
3）对于failover.log日志中的，checkpoint完成，数据库状态ok，只是可以执行select查询（只读），而真正的数据库服务正常，要等待系统启动完成（需要通过sys_log日志确定）。
二、问题总结
对于生产环境，在执行failover切换完成后，新主库需要重启数据库服务，在切换前如果业务压力较大，数据库从最近检查点（failover后checkpoint的上一个检查点）开始启动执行recovery，在此期间数据库处于只读状态，如果有业务连接访问，将出现读写错误，等数据库启动完成后，才能恢复正常读写。
1、如下所示failover前后的checkpoint
2、failover后新主库启动recovery时的checkpoint
三、总结
生产环境中出现问题时，要多结合集群日志及数据库日志进行分析和解决问题。
