KES V8R6读写分离集群故障恢复

KingbaseES V8R6 documentation

1. KingbaseES读写分离集群

«  故障恢复最佳实践   ::   Contents   ::   版本升级最佳实践  »

1. KingbaseES读写分离集群¶

1.1. 简介¶

KingbaseES V8R6 数据库集群在不同的条件，人为操作情况下会出现不同的异常状态，部分异常状态可以自动进行恢复，部分异常状态必须人为手动操作恢复。该文档第一部分归纳KingbaseES V8R6 集群可自动恢复的异常场景。第二部分提供KingbaseES V8R6 集群故障恢复的排查思路和操作。

1.2. 服务器状态要素¶

确认服务器状态，当服务器状态正常时，才能进行自动恢复，或手动恢复集群操作。

表 1.2.10 服务器状态要素 ¶

要素内容	查询命令
服务器是否启动	无
服务器网络状态	ping $trust_ip 查看当前服务器能否ping通信任网关 $trust_ip为集群部署时配置的信任网关
服务器内存状态	free -h 查看是否有足够的内存
服务器磁盘状态	df -h 查看磁盘空间 进入数据库data目录，创建文件，写入内容，读取内容 查看磁盘读写是否正常
服务器防火墙状态	service firewalld status service iptables status 确认防火墙状态，如果防火墙开启，是否白名单配置了数据库端口和sys_securecmdd服务端口8890
SSHD或SYS_SECURECMDD免密状态	ssh/sys_securecmd集群用户@集群其他节点ip 根据集群中use_scmd=on或off使用不同的命令做免密检查。 例如: ssh kingbase@192.168.28.123 例如: sys_securecmd kingbase@192.168.28.123 通过ssh/sys_securecmd命令查看免密是否被破坏
定时任务状态	vim /etc/cron.d/KINGBASECRON 查看kbha进程的定时任务是否为开启状态

1.3. 自动故障恢复¶

1.3.1. 配置方法¶

集群配置文件repmgr.conf配置

表 1.3.7 集群配置文件repmgr.conf配置 ¶

	参数名称	值	备注
恢复配置	recovery	automatic	节点故障后可自动恢复到集群中，需在每个节点配置该参数，重启集群后生效
		standby	故障节点如果是备库，可以自动恢复到集群中；故障节点如果是主库，不做任何操作

1.3.2. 可自动恢复的故障场景¶

表 1.3.8 可自动恢复的故障场景 ¶

故障类型		恢复处理行为		影响
状态变换类故障	集群主库停库	若设置为 automatic ，新主节点会尝试恢复停库节点；若设置为 standby，停库节点之前主库，不恢复		备库repmgr 尝试重连主库阶段业务中断，自动切换完成后恢复
	集群主库节点掉电	节点上电后，同主库停库		同主库停库
	集群主库节点重启	节点重启后，同主库停库		同主库停库
	集群备库停库、掉电、重启或断网	设置standby 或automatic ，主节点会尝试恢复此节点		无业务影响，为不影响业务备库故障可能触发同步流复制转异步
	进程被杀死	repmgrd	由kbha 负责监控，循环拉起，周期约5秒	故障期间不会触发切换
		kbha	由crond负责拉起，1分钟执行一次	故障期间不会触发恢复
		kingbase -主机	同主库停库	同主库停库
		kingbase -备机	同集群备库停库、掉电、重启或断网	同集群备库停库、掉电、重启或断网
	系统崩溃	同主库停库		同主库停库
网络类型故障	备节点防火墙误开启	同集群备库停库、掉电、重启或断网		同集群备库停库、掉电、重启或断网
	集群主节点网络中断	节点网络恢复后，同主库停库		同主库停库
	集群备节点网络中断	同集群备库停库、掉电、重启或断网		同集群备库停库、掉电、重启或断网
	主机网络丢包	10%		无影响
		30%		无影响
		更大的网络丢包率	有概率造成节点网络中断 网络中断同集群备库停库、掉电、重启或断网	同主库停库
	备机网络丢包	10%		无影响
		30%		无影响
		更大的网络丢包率	有概率造成节点网络中断 网络中断同集群备库停库、掉电、重启或断网	同集群备库停库、掉电、重启或断网
资源耗尽类故障	主库存储故障	Repmgr判定主库存储目录读，写，或者读写都失效则实施停库操作 备库识别到主库失联，实施切换 节点存储故障修复后，同主库停库		切换完成之前业务中断
	备库存储故障	备库的 repmgr判定本节点数据目录读，写，或者读写都失效则实施停库操作 主库repmgr识别到备库失效后，若为同步流复制，改为异步 节点存储故障修复后，设置standby 或automatic ，主节点会尝试恢复此节点		备库的存储发生故障后，在主机未从同步模式改为异步模式之前，应用业务写事务会卡住
数据损坏故障	主数据库访问系统表数据、持久化用户表数据、索引时数据块被损坏	当从磁盘读取数据块到缓冲区发现数据块被损坏时（但不包括，备份时发现的坏块），若开启此功能，会在可用的备库中获取正确的块来进行替换修复。此功能有一些其它限制 ,分别为：(1)修复坏块数量不超过系统最大块修复数量；(2)修复坏块数量不超过session级最大块修复数量；(3)修复时间不超过session级最大等待时间；(4)必须有一个存活的备节点；在此约束范围内，功能可以正常工作; (5)如果开启zero_damaged_pages 参数，此参数会在块修复结果后生效		应用访问到的数据中有坏块时，会延迟等待坏块修复结束后返回

1.4. 手动故障恢复¶

1.4.1. 故障排查¶

1.4.1.1. 集群异常状态场景¶

操作指令详见章节： 故障确认操作指令

表 1.4.6 全节点故障-单主 FS001-ANF-SP(All node fault-single primary) ¶

FS001-ANF-SP	操作指令	结果
所有节点全部故障，且故障的节点中只有1个节点为主机	FC-1	所有节点-失败
	FC-3	所有节点-不存在kingbase进程
	FC-7	有且仅有1个节点的data 目录下不存在standby.signal

以上操作指令全部执行且检查结果和表格中结果一致则说明集群所有节点全部故障，且故障的节点中只有1个节点为主机

备机节点先故障，主机节点最后故障，或者所有服务器同时断电或断网会导致全节点故障-单主异常状态

表 1.4.7 全节点故障-多主 FS002-ANF-MP(All node fault-multi primary) ¶

FS002-ANF-MP	操作指令	结果
所有节点全部故障，且故障的节点中有多个节点为主机	FC-1	所有节点-失败
	FC-3	所有节点-不存在kingbase进程
	FC-7	有且2个或以上的节点的data 目录下不存在standby.signal

以上操作指令全部执行且检查结果和表格中结果一致则说明集群所有节点全部故障，且故障的节点中存在2个或多个主机

主机节点先故障，集群切换后，且主机未恢复到集群中时，新主机也故障会导致全节点故障-多主异常状态

表 1.4.8 部分节点故障-存活节点中有主机-单主 FS003-SNF-ASP(Some node fault-alive single primary) ¶

FS003-SNF-ASP	操作指令	结果
部分节点故障，且存活的节点中只有1个节点为主机	FC-1	部分节点-失败 部分节点-成功 其结果一致，结果显示1个primary 节点，其状态是running
	FC-3	执行FC-1失败的节点-不存在kingbase进程 执行FC-1失败的节点-存在kingbase进程

以上操作指令全部执行且检查结果和表格中结果一致则说明集群部分节点故障，存活的节点中存在1个主机节点

集群有节点故障，集群处理正常后，集群状态可用，且会出现部分节点故障-存活节点中有主机-单主状态

表 1.4.9 部分节点故障-存活节点中有主机-多主 FS004-SNF-AMP(Some node fault-alive multi primary) ¶

FS004-SNF-AMP	操作指令	结果
部分节点故障，且存活的节点中有多个节点为主机	FC-1	部分节点-失败 部分节点-成功 其结果显示多个primary 节点，状态是running 。或者显示1个primary 状态是running，且 1个或多个是standby 但其状态是running as primary
	FC-3	执行FC-1失败的节点-不存在kingbase进程 执行FC-1失败的节点-存在kingbase进程

以上操作指令全部执行且检查结果和表格中结果一致则说明集群部分节点故障，存活的节点中存在多个主机节点

集群有节点故障，剩余节点网络不正常。

例如1主4备，1备机故障，剩余的4个节点，主节点和3备机网络分割，3备机中会选举升主出现部分节点故障-存活的节点中有主机-多主

表 1.4.10 部分节点故障-存活节点中没有主机 FS005-SNF-ANP(Some node fault-alive no primary) ¶

FS005-SNF-ANP	操作指令	结果
部分节点故障，且存活的节点中没有节点为主机	FC-1	部分节点-失败 部分节点-成功 其结果显示没有primary，所有存活的节点都是standby
	FC-2	执行FC-1 成功的节点，执行成功 其结果中Paused?的状态为 yes 执行FC-1 失败的节点，执行失败
	FC-3	执行FC-1失败的节点-不存在kingbase进程 执行FC-1失败的节点-存在kingbase进程

以上操作指令全部执行且检查结果和表格中结果一致则说明集群部分节点故障，存活的节点中不存在主机

集群主节点故障，集群备机节点升主失败，或者集群备机的repmgrd服务处于暂停状态(此时执行 repmgr service status发现Paused?为yes)时，会出现部分节点故障-存活的节点中没有主机的异常状态

表 1.4.11 部分节点故障-故障节点中有主机-单主 FS006-SNF-DSP(Some node fault-down single primary) ¶

FS006-SNF-DSP	操作指令	结果
部分节点故障，且故障的节点中只存在一个主机	FC-1	部分节点-失败 部分节点-成功
	FC-3	执行FC-1失败的节点-不存在kingbase进程 执行FC-1失败的节点-存在kingbase进程
	FC-7	执行FC-1失败的节点中有 1个节点的data目录中没有standby.signal文件

以上操作指令全部执行且检查结果和表格中结果一致则说明集群部分节点故障，故障的节点中存在1个主机

集群主节点故障，剩余节点存活，会出现部分节点故障-故障节点中有主机现象

表 1.4.12 部分节点故障-故障节点中有主机-多主 FS007-SNF-DMP(Some node fault-down multi primary) ¶

FS007-SNF-DMP	操作指令	结果
部分节点故障，且故障的节点中存在多个主机	FC-1	部分节点-失败 部分节点-成功
	FC-3	执行FC-1失败的节点-不存在kingbase进程 执行FC-1失败的节点-存在kingbase进程
	FC-7	执行FC-1失败的节点中所有多个节点的data目录中都不存在standby.signal文件

以上操作指令全部执行且检查结果和表格中结果一致则说明集群部分节点故障，故障的节点中存在多个主机

集群主机节点故障，备机升主后也故障，会出现部分节点故障-故障节点中有多个主机现象

表 1.4.13 无节点故障-双主/多主FS008-NNF-MP(No node fault-multi primary) ¶

FS008-NNF-MP	操作指令	结果
无节点故障，但存活的节点中存在多个主机	FC-1	所有节点-成功 其结果显示多个primary 节点，状态是running 。或者显示1个primary 状态是running ，且1个或多个是standby 但其状态是running as primary
	FC-3	所有节点-存在kingbase进程

以上操作指令全部执行且检查结果和表格中结果一致则说明集群出现的双主，或多主

集群主机和备机发生网络切割，备机选举升主，此时出现双主或多主

1.4.1.2. 故障确认操作指令¶

故障确认操作指令编码命名:FC-N(Fault Confirmation)

FC-1:在各节点上执行repmgr cluster show 命令查询集群状态

$bin_path/repmgr cluster show

FC-2:在各节点上执行repmgr service status 命令查询repmgrd服务器状态

$bin_path/repmgr service status

FC-3:在各节点上执行ps -ef|grep kingbase 查看数据库进程是否存在

ps -ef|grep kingbase

FC-4:在各节点上执行ps -ef|grep repmgrd 查看repmgrd进程是否存在

ps -ef|grep repmgrd

FC-5:在各节点上执行ps -ef|grep kbha 查看kbha进程是否存在

ps -ef|grep kbha

FC-6:在各节点上执行ps -ef|grep sys_securecmdd 查看sys_securecmdd进程是否存在(专用机)

ps -ef|grep sys_securecmdd

FC-7:在各节点上检查data目录下是否存在standby.signal文件

FC-8:步骤FC-1如果能查询到结果，ksql -h 主机ip -U system -d test连接主机执行sql

select * from sys_stat_replication;

查看流复制状态

$bin_path/ksql -h 主机ip -U数据库用户 –d 数据库名

select * from sys_stat_replication;

1.4.2. 故障恢复¶

1.4.2.1. 集群恢复思路¶

第一步、确认服务器状态，确保服务器状态正常情况下再进行集群恢复

第二步、确认集群属于哪种异常状态

第三步、备份现场data和日志

第四步、根据异常状态选择集群恢复操作步骤

1.4.2.2. 集群典型异常场景恢复¶

异常场景详见章节： 集群异常状态场景

故障恢复步骤详见章节： 集群恢复操作指令

表 1.4.14 集群典型异常场景恢复 ¶

异常场景	故障恢复步骤 recovery设置manual	故障恢复步骤 recovery 设置为standby	故障恢复步骤 recovery 设置为automatic
FS001-ANF-SP	第一步：FR-2 第二步：FR-5 确认集群状态为正常状态	第一步：FR-2 第二步：FR-5 确认集群状态为正常状态	第一步：FR-2 第二步：FR-5 确认集群状态为正常状态
FS002-ANF-MP	第一步：FR-1 第二步：启动确认的新主数据库 $bin_path/sys_ctl -D $data_path start 第三步：FR-3 如果F R-3执行失败，执行FR-4 第四步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：启动确认的新主数据库 $bin_path/sys_ctl -D $data_path start 第三步：等待备节点自动恢复 在故障主节点上，或自动恢复失败的备节点上，执行FR-4 第四步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：启动确认的新主数据库 $bin_path/sys_ctl -D $data_path start 第三步：等待故障节点自动恢复 如果自动恢复执行失败，执行FR-4 第四步：FR-5 确认集群状态为正常状态
FS003-SNF-ASP	第一步：故障节点执行：FR-3 如果F R-3执行失败，执行FR-4 第二步：FR-5 确认集群状态为正常状态	第一步：等待备节点自动恢复 如果自动恢复执行失败，执行FR-4 如果有故障节点是主机，执行FR-4 第二步：FR-5 确认集群状态为正常状态	第一步：等待故障节点自动恢复 如果自动恢复执行失败，执行FR-4 第二步：FR-5 确认集群状态为正常状态
FS004-SNF-AMP	第一步：FR-1 第二步：除新主机外所有节点执行FR-3 如果F R-3执行失败，执行FR-4 第三步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：除新主机外停止数据库，等待备机自动恢复 $bin_path/sys_ctl -D $data_path stop 在故障主节点上，或自动恢复失败的备节点上，执行FR-4 第三步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：除新主机外停止数据库，然后等待自动恢复 $bin_path/sys_ctl -D $data_path stop 如果自动恢复执行失败，执行FR-4 复执行失败，执行FR-4 第三步：FR-5 确认集群状态为正常状态
FS005-SNF-ANP & FS006-SNF-DSP	第一步：启动故障的主机节点 $bin_path/sys_ctl -D $data_path start 第二步：其他所有节点执行FR-3 如果F R-3执行失败，执行FR-4 第三步：FR-5 确认集群状态为正常状态	第一步：启动故障的主机节点 $bin_path/sys_ctl -D $data_path start 第二步：其他节点停止数据库，等待备机自动恢复 $bin_path/sys_ctl -D $data_path stop 如果自动恢复执行失败，执行FR-4 如果有故障节点是主机，执行FR-4 第三步：FR-5 确认集群状态为正常状态	第一步：启动故障的主机节点 $bin_path/sys_ctl -D $data_path start 第二步：其他节点停止数据库，然后等待自动恢复 $bin_path/sys_ctl -D $data_path stop 如果自动恢复执行失败，执行FR-4 第三步：FR-5 确认集群状态为正常状态
FS005-SNF-ANP & FS007-SNF-DMP	第一步：FR-1 第二步：启动确认的新主数据库 $bin_path/sys_ctl -D $data_path start 第三步：FR-3 如果F R-3执行失败，执行FR-4 第四步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：启动确认的新主数据库 $bin_path/sys_ctl -D $data_path start 第三步：其他节点停止数据库，等待备机自动恢复 $bin_path/sys_ctl -D $data_path stop 如果自动恢复执行失败，执行FR-4 在故障主节点上，执行FR-4 第四步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：启动确认的新主数据库 $bin_path/sys_ctl -D $data_path start 第三步：其他节点停止数据库，然后等待自动恢复 $bin_path/sys_ctl -D $data_path stop 如果自动恢复执行失败，执行FR-4 第四步：FR-5 确认集群状态为正常状态
FS008-NNF-MP	第一步：FR-1 第二步：除新主机外所有节点执行FR-3 如果F R-3执行失败，执行FR-4 第三步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：除新主机外所有节点停止数据库，等待备机自动恢复 $bin_path/sys_ctl -D $data_path stop 如果自动恢复执行失败，执行FR-4 在故障主节点上，执行FR-4 第三步：FR-5 确认集群状态为正常状态	第一步：FR-1 第二步：除新主机外所有节点停止数据库，然后等待自动恢复 $bin_path/sys_ctl -D $data_path stop 如果自动恢复执行失败，执行FR-4 第三步：FR-5 确认集群状态为正常状态

1.4.2.3. 集群恢复操作指令¶

故障恢复操作指令编码命名:FR-N(Fault Recovery)

1.4.2.3.1. FR-1:出现多主时，判断谁是新主¶

时间线：

查看谁的时间线更新，时间线大的是新主机：

数据库运行中，select timeline_id from sys_control_checkpoint();

数据库停止状态，查看控制文件 sys_controldata -D data 中Latest checkpoint's TimeLineID后的数值代表时间线

WAL日志位置(LSN)：

lsn位置大致能够代表用户插入数据多少，lsn大的数据量更多，一般情况下数据量更多的是新主：

数据库运行中，select sys_current_wal_lsn();

数据库停止状态，查看控制文件 sys_controldata -D data 中Latest checkpoint location后的数值代表checkpoint的lsn

控制文件中记录的checkpoint的lsn，一般比当前lsn要小，但差别不是太大。

数据量(Database Size,Table Size)：

一般情况下数据量更多的是新主

查看数据库大小

## 数据库字节数 bytes

select sys_database_size(oid) from sys_database;

## 按照大小，自动选择对应单位，bytes/kB/MB/GB/TB

select sys_size_pretty(sys_database_size(oid)) from sys_database;

查看表大小，每个表查看大小

该值仅代表对应表的数据文件大小（4KB的整数倍），不是实际数据量多少，而且，需要每个数据库、模式、表单独查询。

## 仅查看当前数据库中用户表的大小

select relname, sys_table_size(oid) from sys_class where oid > 16300 and
relkind ='r';

   select relname, sys_size_pretty(sys_table_size(oid)) from sys_class
   where oid > 16300 and relkind = 'r';

## 仅查看当前数据库、当前模式（默认为PUBLIC模式）下用户表的大小


\\d+

   ## 需要查询系统表大小，请单独指定系统表名/OID来查询

1.4.2.3.2. FR-2:一键启动集群¶

在某一个节点上执行sys_monitor start来一键启动集群

$bin_path/sys_monitor.sh start

1.4.2.3.3. FR-3:使用repmgr nodo rejoin恢复成集群备机¶

在故障的节点上执行停止数据库操作

$bin_path/sys_ctl -D $data_path stop

在故障的节点上执行rejoin操作，重归集群

$bin_path/repmgr -h 新主机ip -U esrep -d esrep -p 数据库端口 node rejoin --force-rewind

1.4.2.3.4. FR-4:重做备机¶

停止数据库：

$bin_path/sys_ctl -D $data_path stop

该节点执行standby clone命令(-F参数会覆盖原有data目录)：

$bin_path/repmgr -h 新主机ip -U esrep -d esrep -p 数据库端口 -D  $data_path standby clone -F

启动数据库：

$bin_path/sys_ctl -D $data_path start

注册备机实例到集群(-F 参数会强制注册)：

$bin_path/repmgr standby register -F

1.4.2.3.5. FR-5:查询集群状态¶

查询集群状态 查询到结果，正常状态为只有1个主机，且所有节点状态为running

$bin_path/repmgr cluster show

查询repmgrd服务状态 查询到结果，正常状态为Paused?为no

$bin_path/repmgr service status

查询流复制状态正常状态为查询到所有备机信息

$bin_path/ksql -h 主机ip -U数据库用户 –d 数据库名

select * from sys_stat_replication;

«  故障恢复最佳实践   ::   Contents   ::   版本升级最佳实践  »

© Copyright 1999-2022, 北京人大金仓信息技术股份有限公司. Last updated on Feb 28, 2022. Created using Sphinx 3.3.1.