金仓数据库KingbaseES高可用最佳应用实践（Clusterware）

目录

4.1. KingbaseES Clusterware简介 ¶

4.2. 配置 ¶

4.2.1. 硬件配置 ¶

4.2.2. 操作系统配置 ¶

4.2.3. Clusterware配置 ¶

4.3. 故障处理行为 ¶

4.3.1. 网络类故障 ¶

4.3.2. 状态变化类故障 ¶

4.3.3. 资源耗尽类故障 ¶

4.4. 监控指标 ¶

4.5. 从计划外停机中恢复 ¶

4.5.1. 实例故障、主机/网络故障但存储可用 ¶

4.5.2. 存储故障/数据损坏的恢复 ¶

4.5.3. 集群故障或站点故障的恢复 ¶

4.5.4. FENCE设备故障的恢复 ¶

4.5.5. clusterware备份和恢复方式 ¶

4.6. 计划内停机操作 ¶

4.6.1. 资源补丁、升级 ¶

4.6.2. clusterware补丁、升级 ¶

4.6.3. 系统或硬件补丁、升级 ¶

4.7. 配置变更 ¶

4.7.1. 资源配置 ¶

4.7.2. 成员配置 ¶

4.7.3. 增加删除节点 ¶

---

4.1. KingbaseES Clusterware简介 ¶

KingbaseES Clusterware用于协调多种资源组成统一的服务，配合KingbaseES可以实现以下几种方案：

1. 使用共享存储的高可用方案

   

   图 4.1.35 基于共享存储的高可用方案 ¶

2. 使用共享存储的高可用多活方案，适用于：

   1. 单个应用做了库级的解耦，可以通过分库将压力分散到不同数据库实例。以下是逻辑图示，正常运行情况和单个节点故障的情况：

   

   图 4.1.36 单个应用做库级的解耦 ¶

   1. 多个应用的集约化部署，每个应用使用单个数据库实例。以下是逻辑图示，正常运行情况和单个节点故障的情况：

   图 4.1.37 多个应用的集约化部署 ¶

这些高可用方案和读写分离集群方案的选择和比较请参考 KingbaseES高可用概述 中“功能相近特性的选择”一节。

4.2. 配置 ¶

数据库集群件Clusterware是一个复杂的系统，涉及多个数据库，多个主机，多种资源，多种配置，在用户现场部署运行数据库集群件是一个较为复杂、困难的事情。特编写该文档，对实施在现场部署集群件起到一个规范和指导的作用。本章节分为四部分，第一部分介绍集群部署相关配置，第二部分介绍故障处理行为，第三部分介绍监控指标，第四部分介绍从计划外停机中恢复，第五部分介绍计划内停机操作，第六部分介绍配置变更。

4.2.1. 硬件配置 ¶

4.2.1.1. 限制 ¶

表 4.2.12 限制  ¶

服务器	非专用机，支持IPMI管理，IPMI独立供电
存储设备	SAN/DAS存储阵列，支持ISCSI3以上协议
组网	集群节点在一个子网内
	接入同一交换机，route不超过1跳

4.2.1.2. 推荐配置 ¶

两节点分库方案中共享存储设备需要分成三个LUN，第一个LUN大小100M，作为投票盘，其他两个LUN作为分库的数据存储区域。

4.2.2. 操作系统配置 ¶

和KingbaseES的操作系统配置要求相同。 特别的：建议配置NTP时钟同步。

4.2.2.1. 配置NTP实现时间同步 ¶

1. 环境中有时间服务器的情况下各节点同步时间服务器

   1. 如果时间服务器端有客户端IP限制，加入各节点IP

   2. 各节点在ntp.conf中加入时间服务器配置（以192.168.4.134为例）

   server 192.168.4.134 prefer
   fudge 192.168.4.134 stratum 10
   

2. 环境中没有时间服务器的情况下设置集群中一个节点为NTP服务器，其他节点向此服务器同步时间。 使用此种方式时要注意在NTP服务器节点故障修复后重新加入网络时需要手动检查系统时间，可以设置为比运行节点中时间最快的更快几秒。

   1. NTP服务器节点在ntp.conf中加入向本地时间同步设置（以192.168.4.1为子网IP，以255.255.255.0为子网掩码为例）

   server 127.127.1.0 prefer
   fudge 127.127.1.0 stratum 10
   restrict 192.168.4.1 mask 255.255.255.0
   

   1. NTP客户端各节点在ntp.conf中加入时间服务器配置（以192.168.4.134为例）

   server 192.168.4.134 prefer
   fudge 192.168.4.134 stratum 10
   

4.2.2.2. 终端term配置 ¶

在终端显示时，会用到term，如果term不在默认路径，那么需要进行额外操作。 通过如下命令查看term是否在默认路径

crm_mon

如果出现如下错误,则说明term不在默认路径下

Error opening terminal: xterm.

通过如下find命令查找term.以上报错显示默认term为xterm，也可通过 $TERM 查看默认term

find / -name ${TERM}

通过软连接或者更改默认TERMINFO路径的方式，实现修改(默认路径一般为/usr/share/terminfo/x)

ln -s 实际存在路径 默认路径

或者

export TERMINFO=实际存在路径

4.2.3. Clusterware配置 ¶

4.2.3.1. 投票盘（qdevice-disk）配置 ¶

1. 按以下命令初始化投票盘

mkqdisk -c /dev/设备 -l 自定义名称

1. 查看初始化信息

mkqdisk -f 自定义名称 -d -m

4.2.3.2. 成员管理（corosync）配置 ¶

4.2.3.2.1. 说明 ¶

以下配置无特别说明：

1. 不包括不使用的段

2. 不包括默认的配置值

4.2.3.2.2. TOTEM段 ¶

表 4.2.13 totem段  ¶

配置项	推荐配置和说明
version	固定值2
cluster_name	集群内统一命名即可
Token	单位毫秒，节点的网 络心跳超时时间，超时未收到节点的心跳会认为节点故障。
join	单位毫秒，集群成员协议中做 一致性同步时的超时时间，超时将会延迟成员稳定的时间。
crypto_hash	加密相关 配置，默认关闭但不配置会去系统的配置中获取导致报错。
crypto_cipher	加密相关 配置，默认关闭但不配置会去系统的配置中获取导致报错。

4.2.3.2.3. TOTEM.INTERFACE段 ¶

表 4.2.14 totem.interface段  ¶

配置项	推荐配置和说明
knet_ping_interval	单位毫秒，knet的心跳间隔。
knet_ping_timeout	单位毫秒，在timeout时间 内没有收到ping会认为knet连接断开，和token相似。
mcastaddr	默认设置即可， 如果网络有控制，请找网管分配一个组播地址。
mcastport	默认，占用5405和5404端口。

4.2.3.2.4. NODELIST段 ¶

表 4.2.15 nodelist段  ¶

配置项	推荐配置和说明
ring0_addr	按推荐不使用redundant ring协议，只有ring0_addr。
name	节点名，使用hostname。
nodeid	各节点从1开始顺序增加。

4.2.3.2.5. QUORUM & QUORUM.DEVICE段 ¶

表 4.2.16 quorum & quorum.device段  ¶

配置项	推荐配置和说明
provider	固定值corosync_votequorum
device.timeout	单位毫秒，timeout是corosync等待qdevicevote 的超时，超过超时会导致集群失去quorum停止。
device.sync_timeout	Sync阶段使用，其他和timeout相同。
device.master_wins	固定值1，目前qdisk投票方式为master投票。
device.votes	qdisk的票数， 固定值节点数-1（每个节点1vote，qdisk节点数-1 votes用 于实现只有1节点+qdisk就可以达到quorum要求）。
device.model	固定值disk

4.2.3.2.6. QUORUM.DEVICE.DISK段 ¶

表 4.2.17 quorum.device.disk段  ¶

配置项	推荐配置和说明
device.disk.debug	为了方便现场debug时直接修改配置所以特别保留
interval	单位毫秒，磁盘心跳间隔。
tko	磁盘心跳超 时次数，磁盘心跳丢失超过此次数节点会被认为故障。
tko_up	新启动的集群 磁盘心跳被识别超过此次数后会被认为启动成功。
upgrade_wait	集群启动后开始发起选举至少等待的心跳数。
master_wait	获得满足master 投票，成为master前至少等待心跳的次数。
device	配置qdisk使用的存储设备路径。
Label	使用初始化的lable去查，该字段为了防止linux内核 重启，导致device指定的名字发生改变，设置lable ，就不用device字段指定投票盘，该值有mkqdisk –L指定。
io_timeout	固定值1，qdisk 进程的I/O操作超过tko*interval后会自动会重启。
fence_timeout	单位毫秒，对丢失心跳的节点做fence时的超时时间。

4.2.3.2.7. LOGGING段 ¶

表 4.2.18 logging段  ¶

配置项	推荐配置和说明
to_logfile	除syslog外是否输出log到文件
logfile	文件路径，支持logrotate配置。
debug	off 默认值为off，为了方便现场debug时直接修改配置所以特别保留。

4.2.3.2.8. SYSTEM段 ¶

表 4.2.19 system段  ¶

配置项	推荐配置和说明
state_dir	默认/var/lib/corosync，有文件位置需要可以变更。

4.2.3.2.9. 配置间关系 ¶

1. 两节点集群中不考虑qdisk的多次故障造成的投票时间增加，单次投票在master io故障情况下到新master选举投票的时间最大为：

interval * (tko + master_wait + upgrade_wait) + fence_timeout

1. fence_timeout应小于tko * interval避免因fence导致心跳更新不及时。

2. 考虑bid过程中有新节点的恢复，master_wait要比tko_up大。

3. qdevice的timeout应该大于qdisk单次投票的最大时长避免正常投票过程超时。

4. qdevice的sync_timeout应该大于timeout。

5. corosync的totem应该大于qdisk单次投票的最大时长避免投票过程中的节点变更。

4.2.3.2.10. 两节点推荐配置 ¶

配置见corosync_2nodes.conf

4.2.3.2.11. 配置调整 ¶

1. 在推荐配置基础上修改集群节点数、集群名。

2. 在满足配置间关系的情况下，根据现场RTO需求和网络状况调整各个超时参数，实现更小的RTO或是减少异常干扰。

3. 在专用机环境根据策略调整存储位置。

4.2.3.3. 资源管理（pacemaker）配置 ¶

4.2.3.3.1. 说明 ¶

以下配置无特别说明：

1. 不包括默认的配置值。

2. 描述格式使用crm configure形式。

4.2.3.3.2. CLUSTER OPTIONS ¶

表 4.2.20 集群级别的配置参数  ¶

参数名称	默认值	建议
maintenance-node	false	集 群是否处于维护状态，一般正 常状态，建议为false，当处于 维护状态时，设置为true，为 true时，资源处理不可控状态。
stonith-enabled	true	失败的节点与资源停止不掉的 节点是否进行fence，一般有fence 设备的，需要开启该参数， 没有fence设备的，需要关闭该 参数，否则，资源将不会启动。
stonith-action	reboot	可选值有off 与reboot，执行fence的动作 ，reboot表示重启，off表示关 机，一般来说，建议选默认值。
stonith-timeout	60s	针对fence的超时设置，一 般建议默认值，不过根据fence device情况，可以适当增加。
cluster-delay	60s	DC 指示远程节点执行 执命令，等待操作返回的超时 设置，一般超过该超时，DC没 有得到回应，认为执行失败， 该值需要考虑网络负载情况， 网络速度不足，需要加大该值。
dc-deadtime	20s	节点启动时 ，连接DC的超时设置，一般在 网络速度不足，需要加大该值。
cluster_recheck_interval	15min	Pacemaker一般是事件触发 ，当集群发生某件事情的时候 ，会触发一次schuedule调用， 看要采取什么行动，设置该值 ，代表没有事件发生时，每隔 多长事件触发一次，0表示禁用。

4.2.3.3.3. 资源OPERATION配置 ¶

Pacemaker的资源代理脚本基本上需要支持stop，start，monitor三种操作，每个操作有如下属性可以配置。

表 4.2.21 资源operation配置  ¶

属性名称	默认值	意义
id		唯一性的名称
name		操作的名称，如： monitor，start，stop。
interval	0	操作的频率，0表示在需要 的时候调用，start和stop 操作一般设置为0， monitor需要调整该参数。
timeout		超时设置， 超过该时间，操作没有 反应，默认为失败。
on-fail	restart(如果设置了 fence，那么stop默认的是 fence，如果没有fence， 那么stop默认的是block)	可以配置的值有： ignore 假装没有失败 block 资源不会进一步操作 stop停止资 源，也不在其他地方启动 restart 停止资源，然后启动资源 fence fence失败节点 standby 将资源移到其他节点。
enabled	true	用false表示忽略该操作。
record-pending	true	是否记录操作， 以至于GUI和CLI工具可以 标记该操作正在进行。
role		节点以何种角色运行 该操作，一般有 stopped和started， Slave和Master，目前仅对 多个monitor操作有效。

4.2.3.3.4. 资源META配置 ¶

资源meta属性,设置资源的全局属性,无关资源以何种属性运行

表 4.2.22 资源meta配置  ¶

属性名称	默认值	意义
priority	0	优先级，当不能确保 所有资源都能运行的 情况下，优先确保 高优先级的资源活着。
target-role	Started	集群确保该 资源应该处于什么状态 Stopped: 强迫资源停止 Started：运行 Slave：备模式 Master：主模式
is-managed	true	资源是否允许 clusterware 停止与启动
maintenance	false	资源是否在管 理状态，针对单个资源 true false
resource-stickiness	1 clone资源 0 其他资源	资源保留 在当前运行节点的分数
requires	对fence 资源，默认值为quorum 如果unfencing 处于激活状态 ，默认值为unfencing 如果stonith-enabled 是true，则是fencing 其他则是quorum	资源能运行的必要条件 nothing 始终能运行 quorum 需要获得quorum 才能运行资源 fencing：大部 分节点活着，其他失败 或unknow节点被fenced unfencing： 大部分节点活着， 其他节点都被fence 掉。
migration-threshold	INFINITY	资源在一个节点失 败多少次后迁移到另一 个节点，0表示禁止迁 移。
failure-timeout	0	节点失败次数失效， 0表示禁用该功能。
multiple-active	stop_start	当集群发现资源在多个 节点活着，采取的动作 block: 标记该资源托管 stop_only： 停掉所有资源 stop_start： 停掉所有资源， 然后在一个节点启动。
allow-migrate	ocf： pacemaker:remote资源 是true，其他是false	允许资源或者迁移
container -attribute-target		跟bundle resource相关
remote-node		Pacemaker remote guest node的名字
remote-port	3121	Pacemaker remote guest node port
remote-addr	value of remote-node	配置remote node IP地址
remote -connect-timeout	60s	remote node 连接超时

为了自动清理资源失败的failcount，可以设置资源的Failure-timeout为一个特定的时间：5min,具体见资源配置章节。

4.2.3.3.5. 资源配置 ¶

目前仅以分库方案来看，需要用的资源有fence，FileSystem，Stoarge lock，VIP，KingbaesES，PING，故本章专门介绍这些资源的配置，其实pacemaker还支持很多其他资源。

1）. fence

VMWare ESXi环境

primitive esxi_fence stonith:fence_vmware_soap \
params ipaddr=192.168.4.5 login=root passwd="Kingbase@99"
pcmk_host_check=none ssl=1 ssl_insecure=1 \
op monitor interval=60s \
meta failure-timeout=5min

表 4.2.23 VMWare ESXi环境资源配置  ¶

参数名称	默认值	说明
stonith: fence_vmware_soap	""	配置fence agent类型
ipaddr	""	VMWare ESXi IP地址
login、passwd	""、""	登录用户名、密码
pcmk_host_check	如果配 置了pcmk_host_list或 者pcmk_host_map，那 么此参数的默认值是 static_list。如果以上 两项都没配置，1） fence设备支持list操作， 那么默认值为dynamic_list； 2）fence设置支 持status操作，不支持 list操作，那么默认值 为status。以上条件均 不满足，默认值为none。	若配置none，表示 fenceagent可以 fence全部节点。
ssl、ssl_insecure	""、""	此agent 需要的参数，使用ssl 连接但不验证证书。
其他	""	默认fence action 是reboot，60s超时， 过程中会重试2次。

IPMI环境

primitive fence_node1_ipmi stonith:fence_ipmilan \
params ipaddr=192.168.2.100 login=Administrator passwd="Admin@9000"
pcmk_host_list=node1 lanplus=true
ipmitool_path=/opt/KingbaseHA/ipmi_tool/bin/ipmitool \
op monitor interval=60s \
meta failure-timeout=5min

表 4.2.24 IPMI环境资源配置  ¶

参数名称	默认值	说明
stonith:fence_ipmilan	""	表示fence agent类型
ipaddr	""	此IPMI设备IP地址
login、passwd	""、""	登录用户名、密码
pcmk_host_list	""	此IPMI设备 控制的节点uname列表 由于IPMI 设备一般为各节点独占 ，因此这里一般仅为一 个uname。多节点集群 ，一般需要配置多个 fence_ipmilan资源，分 别支持各节点的fence。
lanplus	0	此agent 需要的参数，使用IPMI LAN(RMCP+)协 议，如服务器支持IPMI LAN(RMCP)协 议，也可不配置此参数。
ipmitool_path	"/usr/bin/ipmitool"	IPMI客户端二进制ipmitool 路径，如不配置， 则会在环境变量中查找。
其他		默认fence action 是reboot，60s超 时，过程中会重试2次。

2）. File System & Storage lock

FileSystem

File SYSTEM资源是一种pacemaker支持的OCF资源，其资源agent脚本位于$OCF_ROOT/resource.d/heartbeat/Filesystem,，主要用于管控文件系统资源，自动将文件系统挂载指定的目录，该脚本提供如下参数：

表 4.2.25 FileSystem脚本参数  ¶

参数名称	默认值	说明
device	""	块设备路径，mount的-U -L指定的设备，或者是 nfsmount的源路劲。
directory	""	挂载点， 文件系统挂载点路径。
fstype	""	文件系统类型
options	""	指定mount的-o属性
statusfile_prefix	.Filesystem_status/	监控状态文件存放位置， 一般按默认处理。
run_fsck	auto	是否执行fsck，auto 表示由fstype决定，force 表示强行执行，no 表示从不执 行，该命令用来修复损坏的 文件系统，一般按默认设置。
fast_stop	yes	期望在没有用户操作时 ，文件系统快速停掉，如果 不能控制文件系统的用户， 设置成no，一般按默认设置。
Force_clones	false	一般来说，使用 clone手段建立本地文件系统 是被禁止的，开启该参数， 将会以clone手段mount一个 文件系统，一般按默认设置。
force_unmount	true	值为true 表示在umount的时 候，kill掉正在访问mount 的路径的进程；safe，以一 种安全的手段kill掉正在访 问mount路径的进程，该安 全手段避免在发现进程时导 致block状态，貌似针对nfs 有效；false 表示不kill掉正在访问 的进程，一般建议用默认值。

另外该脚本还支持在监控时，进行深度操作，即OCF_CHECK_LEVEL值的设置，目前支持两个值：

20：往磁盘中可读可写，只有可读可写，文件系统才算正常

10：往磁盘中可读，只要可读，文件系统就算正常。

配置实例：将/dev/sdc的ext4文件系统挂载到/sharedata/data1目录下，需要确保/sharedata/data1目录优先存在。

由于在linux中/dev/sdx是由内核加载硬盘顺序决定的，存在着不确定性，故建议使用UUID挂载磁盘。

1. 使用如下命令查看/dev/sdc 的uuid

blkid /dev/sdc
/dev/sdc: UUID="c2db7022-444f-4cbe-b452-0301c2387ffc" TYPE="ext4"

1. crm 配置资源

crm configure primitive FILESYSTEM1 ocf:heartbeat:Filesystem \
params device="-U c2db7022-444f-4cbe-b452-0301c2387ffc"
directory="/sharedata/data1" fstype="ext4" \
op start interval="0" timeout="60" \
op stop interval="0" timeout="60" \
op monitor interval="30s" timeout="60" OCF_CHECK_LEVEL="20" \
meta failure-timeout=5min

Storage lock

Storage lock是一种ocf资源，其agent脚本为sg_persist，位于$OCF_ROOT/resource.d/heartbeat/sg_persist目录下，该资源是为保护共享磁盘只被一个node访问。

该脚本提供的参数如下：

表 4.2.26 Storage lock参数  ¶

参数名称	默认值	意义
binary	sg_persist	管理资 源的二进制程序，按默认值。
devs	""	管理的磁盘设备
required_devs_nof	1	管理磁盘的 最小数目，按默认值。
reservation_type	1	配置reservation type ，保护模式使用独占模式:3。
master_score_base	0	配置master基础分数 ，设置越高，该节点越容易 成为master，一般按默认值。
master_score_dev_factor	100	对 master_score计算的device 因子，一般按默认值。
master_score_delay	30	主备 减少或增加其master_score 之前的延时时间，以s为 单位，一般按默认处理。

配置实例如下，实现在mount文件系统前先独占存储的LUN防止双挂。

primitive sg sg_persist \
params devs="/dev/sdc" reservation_type=3 \
op monitor interval=30 timeout=60 \
meta failure-timeout=5min
ms disk_reserve sg \
meta master-max=1 notify=true target-role=Master
order storage-order Mandatory: disk_reserve:promote FILESYSTEM1:start
colocation storage-colocation inf: DB1_GROUP disk_reserve:Master

3）. VIP

VIP是一种ocf类型的资源，其代理脚本在$OCF_ROOT/resource.d/heartbeat/IPaddr2，该资源能提供虚拟IP地址服务。Agent提供的参数如下：

表 4.2.27 VIP参数  ¶

参数名称	默认值	意义
ip	""	IPv4 或 IPv6的地址
nic	""	IP地址绑定的接口名称
cidr_netmask	""	CIDR netmask，如24
broadcast	""	广播地址，一般按默认。
iflabel	""	Interfacelabel， 该label会加到接口名 称的后面，一般按默认。
lvs_support	false	针对IPv4有效， 是否支持 LVSDirect Routing配 置，当该IP地址down掉 是，将其移送到loopback 接口上,一般按默认。
lvs_ipv6_addrlabel	false	开启IPv6的LVS Direct Routing配置
lvs_ipv6_addrlabel_value	99	启动IPv6 address label
clusterip_hash	" sourceip-sourceport"	配置cluster IP的哈希 算法
mac	""	IP的MaC地址， 若为空，将会自动选择。
unique_clone_address	False	是否clone一个address
arp_interval	200	ARP packet interval in ms
arp_count	5	ARP 包的个数
arp_count_refresh	0	配置monitoring 节点发送ARP包的个数
arp_bg	true	是否 以后台进程发送ARP包
arp_sender	send_arp	发送ARP包 方式：send_arp，使用 heartbeat自带的send_arp 程序；ipoibarping infiniband 接口的默认 方式；iptuils_arping 使用iputils 包的 方式；libnet_arping 使用libnet方式。
send_arp_opts	""	配置arp_sender 程序的options
flush_routes	"false"	Stop时候是否刷路由表
run_arping	false	是否在IPv4 collision detection check中使用arping
noprefixroute	"false"	使用noprefixroute 标识
preferred_lft	"forever"	针对 IPv6，设置其lifetime
network_namespace	""	指定network namespace

配置实例如下：

crm configure primitive FIP1 ocf:heartbeat:IPaddr2 \
params ip="192.168.4.135" cidr_netmask="32" nic="bond0" \
arp_sender="iputils_arping" \
op monitor interval="30s" timeout="60s" \
op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s" \
meta failure-timeout=5min

4）. KingbaseES

该资源是针对KingbaseES，agent脚本为$OCF_ROO/resource.d/kingbase/kingbase，该脚本提供参数如下：

表 4.2.28 kingbase参数  ¶

参数名称	默认值	意义
sys_ctl	/opt/Kingbase/ES/V8/Server/bin/sys_ctl	指定sys_ctl命令位置 ，用于控制数据库启停。
ksql	/opt/Kingbase/ES/V8/Server/bin/ksql	Ksql的位置，用来判断 KingbaseES服务是否安装。
sys_isready	/opt/Kingbase/ES/V8/Server/bin/sys_isready	指定sys_isrady位置， e用于monitor。
kb_data	/opt/Kingbase/ES/V8/data	指定KingbaseES的data 目录位置
kb_dba	kingbase	指 定KingbaesES的OS属主
kb_user	system	指定监 控连接的数据库用户名
kb_host	"localhost"	指定KingbaseES监听 的IP地址,0.0.0.0表示 监听本机上所有IP地址。
kb_port	54321	指定 KingbaseES监听的端口
kb_libs	/opt/Kingbase/ES/V8/Server/lib	指 定KingbaseES的lib目录
start_opt	""	使用sys_ctl 启 动时的参数，一般指-o 。
ctl_opt	""	配置sys_ctl的参数， 一般指-w或-W类。
config	kb_data/kingbase.conf	指定kingbase.conf位置
kb_db	template1	监控连接的database 名称
logfile	/dev/null	指定日志的位置
socketdir	""	指 定unix_socket的位置， 在kingbase.conf中设置 了unix_socket_directories ，则需要指定该值。
stop_escalate	90	在使用-m immediate停止 之前，需要等待使用-m fast停止的 超时时间，单位为：秒。
check_wal_receiver	"false"	是否监控wal_receive 进程
monitor_times	10	在monitor阶段， 执行sys_isready 命令的最大次数。
monitor_interval	1	在monitor阶段，上 一次sys_isready执行失 败后，间隔多久进行下 一次执行，单位为：秒。

实例配置：

crm configure primitive DB2 ocf:kingbase:kingbase \
params sys_ctl="/home/kingbase/V8/Server/bin/sys_ctl" \
ksql="/home/kingbase/V8/Server/bin/ksql" \
sys_isready="/home/kingbase/V8/Server/bin/sys_isready" \
kb_data="/sharedata/data2/data" \
kb_dba="kingbase" kb_host="0.0.0.0" \
kb_user="system" \
kb_port="36322" \
kb_libs="/home/kingbase/V8/Server/lib" \
kb_db="template1" \
logfile="/home/kingbase/V8/Server/log/kingbase2.log" \
op start interval="0" timeout="120" \
op stop interval="0" timeout="120" \
op monitor interval="9s" timeout="30" \
meta failure-timeout=5min

5）. PING

该资源提供PING服务，一般针对服务器的连通性，属于OCF资源类，其agent位于$OCF_ROOT/resource.d/pacemaker/ping,其提供的参数如下：

表 4.2.29 PING参数  ¶

参数名称	默认值	意义
pidfile	"{HA_VARRUN%%/}/ping-{HA_VARRUN%%/}/ping-{OCF_RESOURCE_INSTANCE}"	PID file
dampen	5s	等待dampening 发生改变的时间
name	pingd	配置attributes name，可以 被constraint使用。
multiplier	1	连 接的ping节点加权因素
host_list	""	配置ping的目标地址， 可以有多个，以空格 隔开。
attempts	3	配置ping重试次数
timeout	2	超时设置，单位s。
options	""	配置ping的options
failure_score	0	失败的分数， 当得分小于该分数是， 认为资源失败。
failure_action	""	设置该值， 在ping失败时调用。
failure_retries	1	失败尝试次数
failure_retry_interval	1	重新尝试的 间隔时间，单位:s 。
use_fping	1	当fping可用时， 使用fping代替ping.
debug	false	是否开 启每个call的详细日志

配置实例如下：

crm configure primitive PINGD ocf:pacemaker:ping \
params host_list="192.168.4.1" multiplier="100" name="ping-in" \
failure_score="100" failure_action=”reboot”failure_retries=3 \
op monitor interval="2" timeout="60" \
op start interval="0" timeout="60" \
op stop interval="0" timeout="60" \
meta failure-timeout=5min

6）. 时间同步

clusterware本身不受系统时间同步与否的影响，节点间的时间同步会影响应用的时间戳记录和发生问题时对log的排查效率。配置方式参见操作系统配置一节。为了防止时间倒退对数据库和业务造成的影响，保持集群中的单一NTP服务器。

4.2.3.3.6. 资源约束配置 ¶

Pacemaker一般可以配置资源的约束，目前来说，比较流行的有location约束，order约束，colocation约束等。

Location 约束配置资源偏好在哪个节点启动；

Order 约束配置各个资源启动的先后顺序；

Colocation 约束配置资源的结合性。

每个资源约束有个分数，pacemaker会根据分数来进行操作，pacemaker会计算每个资源和节点的分数，一般来说，资源在某个节点的分数为负数，则该节点不允许运行该资源，而pacemaker会选择在资源得分最高的节点上运行该资源。

Location约束有如下属性：

表 4.2.30 Location约束属性  ¶

属性名称	默认值	意义
id		全局唯一名称
rsc		约束的 资源名称，和rsc-pattern必须提供一个。
rsc-pattern		POSIX类的正则表达式，模糊匹 配约束资源的名称，和rsc必须提供一个。
node		约束指定的节点名称
score		该约束的分数
resource-discovery	always	是否检测该资源已经运行，有如下值： always 总是检测资源在各个节点是否运行 never 从不检测 exclusive 总是检测资源 在本节点是否运行，不管其他节点。

配置实例如下：

如下实例 配置FIP1 在 node1上运行的分数为1000

crm configure location FIP1-on-node1 FIP1 1000: node1

Order约束能够配置资源启动的顺序，资源不一定在一个节点上启动，其主要有如下属性

表 4.2.31 Order约束属性  ¶

属性名称	默认值	意义
id		一个约束的唯一名称
firist		Then资源依赖资源的名称
then		依赖资源名称
first-action	start	配置firsit资源优先 的操作，合理值有：start start ，stop，promote， demote。
then-action	first-action	配置first资源的 first-action完成后， then资源的操作，合理值 有：start，stop， promote，demote。
kind	mandatory	约束具体实现的方式： - mandatory 只有first-action 成功执行后，then-action 才会执行，硬依赖 - optional：在同一个 操作事务中维持该约束 - serialize 确保涉 及的操作，从不并行运行， first-actin和then-actin 可以以不同 的顺序运行，但一定要一个 完成后，另一个才能完成。
symmetrical	TRUE for mandatory and optional kinds. FALSE for serialize kind	如果为true，那么相反 操作适用相反的顺序，如B start 在A start之后，那么B stop 在A stop 之前。

配置实例如下：

CLONE-PINED资源必须在DB1_GROUP资源启动之前启动，而CLONE-PINGD资源关闭需在DB2_GROUP停止后。

crm configure order cluster-order1 CLONE-PINGD DB1_GROUP

Colocation 约束能够配置资源的结合性，其属性如下：

表 4.2.32 Colocation约束属性  ¶

属性名称	默认值	意义
id		该约束的唯一名称
rsc		需要与with-rsc放在一块的资源名称
with-rsc		配置colocatoin约束的目标资源名称 ，一般来说，clusterware会优先决定那个节 点运行该资源，然后决定rsc资源放在哪运行。
node-attribute	#uname	运行rsc和with-rsc资源的该值必须一致
score		该约束的分 数，+INFINITY表示两个资源永远在一块运行 ，-INFINITY表示两个资源永远不再一块运行。

配置实例：

crm configure colocation cluster-colo1 inf: DB1_GROUP CLONE-PINGD

4.2.3.3.7. 资源迁移分数配置 ¶

Pacemaker可以设置资源迁移的分数，通过合理设置资源保留当前节点运行的分数，能够达到高可用与负载均衡的平衡点。

如果考虑高可用性，即重启节点，不对资源产生迁移，需确保location约束的分数+该分数都大于最大的location得到的分数，如果考虑性能，即资源负载问题，那么需要将该值设置的越小越好

配置实例，将资源迁移分数配置为500。

crm configure rsc_defaults resource-stickiness=500

4.2.3.3.8. GROUP资源与CLONE资源 ¶

1）. Group资源

通常来说，集群可能存在一系列资源，这些资源需要运行在一起，启动顺序有严格要求，停止有相反的顺序，当然可以通过location，order，colocation约束能达到该要求，但配置起来较麻烦，为了简化配置，pacemaker提供group资源的概念。

表 4.2.33 Group资源的属性  ¶

属性名称	默认值	意义
id		唯一的组名称

配置实例：

将FIP1，FILESYSTEM1 DB1三个资源作为一个组资源:

crm configure group DB1_GROUP FIP1 FILESYSTEM1 DB1

上述组中的资源有如下行为特性：

• coLocation 约束，FIP1 FILESYSTEM1 DB1 需要在一块运行;

• Order 约束：启动顺序：FIP1->FILESYSTEM1->DB1, 停止顺序：DB1->FILESYSTTEM1->FIP1;

• FIP1的启动情况，影响FILESYTEM1和DB1，同理FILESYTEM1的启动情况，影响DB1，意思是排在前面的服务没有运行，后面的服务永远不会运行，而排在后面的服务不会对排在前面的服务造成影响;

• 对资源迁移参数resource-stickiness的影响，如果该值为100，那么如果组资源有5个活动资源，那么该组资源留在本节点的分数就是500。

2）. Clone资源

Clone资源是在同一时刻存在多个副本运行，可以让你在每个节点都运行该资源，可以clone一个primitive（普通的资源）和一个group资源。

Clone资源分为anonymous 和globally unique，anonymous比较简单，每个节点运行同样的一份，而globally unique每个节点运行有其特殊性。

表 4.2.34 clone资源的属性  ¶

属性名称	默认值	意义
id		唯一的名称

配置实例如下：

将PINGD资源 打造成clone资源

crm configure clone CLONE-PINGD PINGD

4.2.3.3.9. 两节点双库推荐配置 ¶

1）. 手动配置

使用Clusterware自带的crm工具，手工配置两节点双库。

1. 添加fence资源

   1.1 支持VMWARE ESXi环境的配置，参数ipaddr、login、passwd取值根据需要调整,需要特别注意的是各个机器的主机名要与VMWARE ESXi上的名称一致。

   crm configure primitive esxi_fence stonith:fence_vmware_soap \
   params ipaddr=192.168.4.5 login=root passwd="Kingbase@99"
   pcmk_host_check=none ssl=1 ssl_insecure=1 \
   op monitor interval=60s \
   meta failure-timeout=5min
   

   1.2 支持IPMI环境的配置，参数ipaddr、login、passwd取值根据需要调整。需要注意的是，由于IPMI设备一般为各节点独占，因此需要配置两个fence资源，分别支持node1和node2的fence。

   crm configure primitive fence_node1_ipmi stonith:fence_ipmilan \
   params ipaddr=192.168.2.100 login=Administrator passwd="Admin@9000"
   pcmk_host_list=node1 lanplus=true
   ipmitool_path=/opt/KingbaseHA/ipmi_tool/bin/ipmitool \
   op monitor interval=60s \
   meta failure-timeout=5min
   

   crm configure primitive fence_node2_ipmi stonith:fence_ipmilan \
   params ipaddr=192.168.2.101 login=Administrator passwd="Admin@9000"
   pcmk_host_list=node2 lanplus=true
   ipmitool_path=/opt/KingbaseHA/ipmi_tool/bin/ipmitool \
   op monitor interval=60s \
   meta failure-timeout=5min
   

   执行如下命令，对fence_node1_ipmi和fence_node2_ipm添加location约束。为了保证fence_node1_ipmi资源尽量不在节点node1，fence_node2_ipmi资源尽量不在节点node2，从而减少fence自己的概率，又由于资源在各个节点的默认分数为0，因此需要保证fence_node1_ipmi资源在node2的分数、fence_node2_ipmi在node1的分数均大于rsc_defaults resource-stickiness的分数。

   crm configure location fence_node1_ipmi-on-node2 fence_node1_ipmi 1000: node2
   crm configure location fence_node2_ipmi-on-node1 fence_node2_ipmi 1000: node1
   

2. 执行如下命令，添加FIP1资源,cidr_netmask与原有接口的ip地址的netmask保持一致，集群中各节点都具有此同名网卡接口，可以用ip addr命令查看。

   crm configure primitive FIP1 ocf:heartbeat:IPaddr2 \
   params ip="192.168.4.135" cidr_netmask="24" nic="bond0" \
   arp_sender="iputils_arping" \
   op monitor interval="30s" timeout="60s" \
   op start interval="0" timeout="60s" \
   op stop interval="0" timeout="60s" \
   meta failure-timeout=5min
   

3. 执行如下命令，添加FIP2资源，cidr_netmask与接口原有的ip地址的netmask保持一致，集群中各节点都具有此同名网卡接口，可以用ip addr命令查看。

   crm configure primitive FIP2 ocf:heartbeat:IPaddr2 \
   params ip="192.168.4.136" cidr_netmask="24" nic="bond0" \
   arp_sender="iputils_arping" \
   op monitor interval="30s" timeout="60s" \
   op start interval="0" timeout="60s" \
   op stop interval="0" timeout="60s" \
   meta failure-timeout=5min
   

4. 执行如下命令，添加FILESYSTEM1资源，需确保每个节点/sharedata/data1目录存在，sharedata属主是root，在mount后将data1属主改成数据库用户，c2db7022-444f-4cbe-b452-0301c2387ffc为磁盘的uuid，可以用blkid去查。

   crm configure primitive FILESYSTEM1 ocf:heartbeat:Filesystem \
   params device=" U c2db7022-444f-4cbe-b452-0301c2387ffc"
   directory="/sharedata/data1" fstype="ext4" \
   op start interval="0" timeout="60" \
   op stop interval="0" timeout="60" \
   op monitor interval="30s" timeout="60" OCF_CHECK_LEVEL="20" \
   meta failure-timeout=5min
   

5. 执行如下命令，添加防止FILESYSTEM1双挂服务。

   crm configure
   primitive SG1 ocf:heartbeat:sg_persist \
   params devs="/dev/sdc" reservation_type=3 \
   op monitor interval=30 timeout=60 \
   meta failure-timeout=5min
   ms disk_reserve1 SG1 \
   meta master-max=1 notify=true target-role=Master
   order storage-order Mandatory: disk_reserve1:promote FILESYSTEM1:start
   colocation storage-colocation inf: DB1_GROUP disk_reserve1:Master
   

6. 执行如下命令，添加FILESYSTEM2，需确保每个节点/sharedata/data2目录存在，sharedata属主是root，在mount后将data1属主改成数据库用户，xxxuid 为另一磁盘的uuid，可以用blkid命令去查。

   crm configure primitive FILESYSTEM2 ocf:heartbeat:Filesystem \
   params device="-U xxxxuid" directory="/sharedata/data2" fstype="ext4" \
   op start interval="0" timeout="60" \
   op stop interval="0" timeout="60" \
   op monitor interval="30s" timeout="60" OCF_CHECK_LEVEL="20" \
   meta failure-timeout=5min
   

7. 执行如下命令，添加防止FILESYSTEM2双挂服务。

   crm configure
   primitive SG2 ocf:heartbeat:sg_persist \
   params devs="/dev/sdd" reservation_type=3 \
   op monitor interval=30 timeout=60 \
   meta failure-timeout=5min
   ms disk_reserve2 SG2 \
   meta master-max=1 notify=true target-role=Master
   order storage-order Mandatory: disk_reserve2:promote FILESYSTEM1:start
   colocation storage-colocation inf: DB2_GROUP disk_reserve2:Master
   

8. 执行如下命令，添加PINGD资源，ping网关，测试对应用的连通性，目前来说,由于发生网络分区的时候，当分区节点数一致时，我们总是选择最小节点号id所在分区当选，然而有时候，选出来的集群对外服务不可用，显然不合理，目前为了规避这种情况，将ping资源添加failure_action和failure_retries参数，让不能对外提供服务的节点重启，待后面正式根据heuristics测试结果来选主的时候，再去掉。

   crm configure primitive PINGD ocf:pacemaker:ping \
   params host_list="192.168.4.1" multiplier="100" name="ping-in" \
   failure_score="100" failure_action=”reboot”failure_retries=3 \
   op monitor interval="2" timeout="90" \
   op start interval="0" timeout="90" \
   op stop interval="0" timeout="90" \
   meta failure-timeout=5min
   

9. 执行如下命令，将PIND资源，变成clone资源。

   crm configure clone CLONE-PINGD PINGD
   

10. 执行如下命令，添加一个分库资源，注意/sharedata/data1/data目录下的kingbase.conf需要手动配置port=36321，需要手动创建/home/kingbase/V8/Server/log目录。

    crm configure primitive DB1 ocf:kingbase:kingbase \
    params sys_ctl="/home/kingbase/V8/Server/bin/sys_ctl" \
    ksql="/home/kingbase/V8/Server/bin/ksql" \
    sys_isready="/home/kingbase/V8/Server/bin/sys_isready" \
    kb_data="/sharedata/data1/data" \
    kb_dba="kingbase" kb_host="0.0.0.0" \
    kb_port="36321" \
    kb_user="system" \
    kb_libs="/home/kingbase/V8/Server/lib" \
    kb_db="template1" \
    logfile="/home/kingbase/V8/Server/log/kingbase1.log" \
    op start interval="0" timeout="120" \
    op stop interval="0" timeout="120" \
    op monitor interval="9s" timeout="30" \
    meta failure-timeout=5min
    

11. 执行如下命令，添加另一个分库资源，需要修改相应的/sharedata/data2/data/kingbase.conf中的port为36322。

    crm configure primitive DB2 ocf:kingbase:kingbase \
    params sys_ctl="/home/kingbase/V8/Server/bin/sys_ctl" \
    ksql="/home/kingbase/V8/Server/bin/ksql" \
    sys_isready="/home/kingbase/V8/Server/bin/sys_isready" \
    kb_data="/sharedata/data2/data" \
    kb_dba="kingbase" kb_host="0.0.0.0" \
    kb_user="system" \
    kb_port="36322" \
    kb_libs="/home/kingbase/V8/Server/lib" \
    kb_db="template1" \
    logfile="/home/kingbase/V8/Server/log/kingbase2.log" \
    op start interval="0" timeout="120" \
    op stop interval="0" timeout="120" \
    op monitor interval="9s" timeout="30" \
    meta failure-timeout=5min
    

12. 执行如下命令，创建DB1组资源。

    crm configure group DB1_GROUP FIP1 FILESYSTEM1 DB1
    

13. 执行如下命令，创建DB2组资源。

    crm configure group DB2_GROUP FIP2 FILESYSTEM2 DB2
    

14. 添加DB1 location约束,多个节点，最好分数不一样。

    crm configure location DB1-on-node1 DB1_GROUP 1000: node1
    crm configure location DB1-on-node2 DB1_GROUP 800: node2
    

15. 添加DB2 location约束,为了达到负载均衡，DB2资源的在各个节点的分数要和VIP2正好相反。

    crm configure location DB2-on-node1 DB2_GROUP 800: node1
    crm configure location DB2-on-node2 DB2_GROUP 1000: node2
    

16. 执行如下命令，创建资源约束。

    crm configure colocation cluster-colo1 inf: DB1_GROUP CLONE-PINGD
    crm configure colocation cluster-colo2 inf: DB2_GROUP CLONE-PINGD
    

17. 设置资源保留在原节点的分数，如果考虑高可用性，即重启节点，不对资源产生迁移，需确保location约束的分数 + 该分数都大于最大的location得到的分数，如果考虑性能，即资源负载问题，那么需要将该值设置的越小越好。

    crm configure rsc_defaults resource-stickiness=500
    

2）. 配置文件

配置见crm_2nodes.txt

4.2.3.3.10. 配置调整 ¶

1. 根据现场环境，调整上述环境参数的值，主要涉及具体环境。

2. 根据现场环境，调整各个资源的timeout参数。

   当一台物理宿主机上搭建过多的虚拟机时，会导致虚拟机各方面的性能下降明显。

   建议调高FileSystem的监控超时时间，也就是monitor操作的tiemout时间设置大一些，也可调整磁盘调度。

   建议调高数据库的监测次数，也就是monitor_times设置大一些。

   建议增加环境变量HA_stonith_rhcs_get_metadata_timeout。这个环境变量是控制获取fence资源metadata的超时时间。开机后，执行time fence_vmware_soap -o metadata，如果执行时间超过5s，那么建议将环境变量HA_stonith_rhcs_get_metadata_timeout设置为上述执行时间的两倍。

3. 根据高可用性，调整资源迁移分数，来达到高可用与负载均衡的平衡。

4.3. 故障处理行为 ¶

在使用以上配置时的故障处理行为如下，故障的恢复请参考从计划外停机中恢复一节的内容。

4.3.1. 网络类故障 ¶

表 4.3.3 网络类故障  ¶

故障类型	故障处理行为			业务影响
网络类故障	数据库端口占用		故障节点节点会尝试重启数据库资源，达到 timeout（120s）后转移资源至另外节点。	1.数据库端口被占用后业务中断 2.资源转移成功后业务恢复正常
	网络中断		1. 对于节点整个网络中断（不包含ipmi）， 节点会在检测网络中断30s后重启服务器， 重启后该节点资源会转移至可用节点； 2. 对于心跳线网络中断，此时主节点会 fence备机节点并转移资源至可用节点。	1.网络中断后业务中断 2.资源转移成功后业务恢复正常
	网络 丢包	10%	服务正常，未触发资源故障。	业务正常，有一定延迟。
		>10%	服务正常，未触发资源故障。	业务延迟较大，出现超时报错。
	网络 延迟	0.5s-5s	服务正常，未触发资源故障。	业务延迟较大，出现超时报错。
	网络 单次 分区	1:1	1.选取qdevice的master所在集群为可用节点 (2节点集群，id小的节点会升级为master)。 2.Fence其他节点 3.转移资源至可用节点	1.节点被fence后数据库业务中断 2.数据库资源转移成功后恢复正常
		1:2	1.节点数量为2的集群获得quorum 节点数量为1的节点失去quorum 2.Fence失去quorum节点 3.转移资源至可用节点	1.被fence节点数据库业务中断 2.数据库资源转移成功后恢复正常
		1:1:1	1.网络分区后，节点id小的节点获得quorum 2.获得quorum的节点fence其它节点 3.转移资源到获得quorum的节点	1.被fence节点数据库业务中断 2.数据库资源转移成功后恢复正常
	网关失联		节点会在检测网络中断30s后重启服务器， 重启后该节点资源会转移至可用节点。	1.资源开始转移后数据库业务中断 2.数据库资源转移成功后恢复正常

4.3.2. 状态变化类故障 ¶

注意

目前资源的stop操作on-fail设置是fence，如果进程的hang导致资源的stop无法完成会导致节点被fence，即使已经没有其他可用节点。

表 4.3.4 状态变化类故障  ¶

故障类型	故障处理行为			业务影响
状态变化 类故障	关机		1.Fence故障节点（关机后的节点会因fence 操作重启） 2.转移故障节点资源到可用节点	1.数据库节点关机后业务中断 2.数据库资源转移成功后恢复 正常
	掉电 （IPMI电源保持）		1.Fence故障节点 2.转移故障节点资源到可用节点 3.若节点长期掉电或因硬件损坏导致无法启动 ，会因fence失败导致资源无法正确转移。	1.数据库节点关机后业务中断 2.数据库资源转移成功后恢复 正常
	重启		1.Fence故障节点（reboot的节点可能会在 reboot过程中再次被fence触发reboot） 2.转移故障节点资源到可用节点	1.数据库节点关机后业务中断 2.数据库资源转移成功后恢复正常
	数据库意外关闭		pacemaker在检测到数据库down掉后自动 重启数据库	1.数据库停止后业务中断 2.数据库重启成功后恢复正常
	进程 异常 终止	pacemaker （DC）	1.可用节点会当选为DC节点 2.Fence故障节点 3.转移故障节点资源到可用节点	1.数据库节点被fence后业务中断 2.数据库资源转移成功后恢复 正常
		pacemaker （非DC）	1.Fence故障节点 2.转移故障节点资源到可用节点	1.数据库节点被fence后业务中断 2.数据库资源转移成功后恢复 正常
		pacemaker-co ntrold	Pacemaker主进程会在检测到pacemaker-co ntrold意外退出后重新生成 pacemaker-controld进程	无影响
		pacemaker-b ased	1.Pacemaker主进程会在检测到pacemaker-b ased意外退出后重新生成 pacemaker-based进程 2.DC节点的pacemaker-based进程故障可能 导致该节点被fence	无影响
		pacemaker-f enced	Pacemaker主进程会在检测到pacemaker-f enced意外退出后重新生成 pacemaker-fenced进程	无影响
		pacemaker-e xecd	Pacemaker主进程会在检测到pacemaker-e xecd意外退出后重新生成 pacemaker-execd进程	无影响
		pacemaker-a ttrd	Pacemaker主进程会在检测到pacemaker-a ttrd意外退出后重新生成 pacemaker-attrd进程	无影响
		pacemaker-s chedulerd	Pacemaker主进程会在检测到pacemaker-s chedulerd意外退出后重新生成 pacemaker-schedulerd进程	无影响
		corosync	1.Fence故障节点 2.转移故障节点资源到可用节点	1.故障节点数据库被fence后业务 中断 2.数据库资源转移成功后恢复正常 3.恢复时长： fence成功时间+资 源转移成功时间，总时间大于20s。
		corosync -qdevice (master)	1.slave节点的corosync-qdevice检测到主节 点corosync-qdevice故障后升级自己为 主节点 2.Fence故障节点 3.转移故障节点资源到可用节点	1.故障节点数据库被fence后业务 中断 2.数据库资源转移成功后恢复正常 3.恢复时长：fence成功时间+资源 转移成功时间，总时间大于3min。
状态 变化类 故障		corosync-qde vice(slave)	1.Fence故障节点 2.转移故障节点资源到可用节点	1.故障节点数据库被fence后业务 中断 2.数据库资源转移成功后恢复正常 3.恢复时长：fence成功时间+资源 转移成功时间，总时间大于3min。
		kingbase	pacemaker在检测到数据库进程故障后自动 重启数据库	数据库进程故障后业务中断 数据库重启成功后恢复正常 恢复时长：10s内。
	进程 hang	pacemaker (DC)	1.hang住节点的crm_mon无法查看集群状态 2.资源保持当前状态不变 3.此时集群发生故障无法进行故障转移—集群 失去高可用 4.恢复hang住的pacemaker后该节点资源会 重启	1.Pacemaker进程hang住后业务 可正常运行 2.hang住的pacemaker恢复后 资源会重启
		pacemaker (非DC)	1.hang住节点的crm_mon无法查看集群状态 2.资源保持当前状态不变 3.此时集群发生故障无法进行故障转移—集群 失去高可用	1.不影响，期间该节点会失去高 可用。
		corosync	1.Fence故障节点 2.转移故障节点资源到可用节点	1.故障节点数据库被fence后业务 中断 2.数据库资源转移成功后恢复正常
		corosync -qdevice (master)	1.slave节点的corosync-qdevice检测到主节 点corosync-qdevice故障后升级自己为 主节点 2.Fence故障节点 3.转移故障节点资源到可用节点	1.故障节点数据库被fence后业务 中断 2.数据库资源转移成功后恢复正常
		corosync -qdevice (slave)	1.Fence故障节点 2.转移故障节点资源到可用节点	1.故障节点数据库被fence后业务 中断 2.数据库资源转移成功后恢复正常
		kingbase	1.pacemaker在检测到数据库故障后尝试在 故障节点停止数据库 2.停止超时后，将故障节点的fail-count-DBX 置为INFINITY。 3.Fence故障节点 4.转移故障节点资源到可用节点	1.数据库进程hang住后业务中断 2.数据库资源转移成功后恢复正常
	系统崩溃		1.Fence故障节点 2.转移故障节点资源到可用节点	1.数据库节点系统崩溃后业务中断 2.数据库资源转移成功后恢复正常
	系统时间跳变		1.集群状态正常，业务正常运行。 2.一段时间后ntpd自动正确同步时间。	无影响

4.3.3. 资源耗尽类故障 ¶

表 4.3.5 资源耗尽类故障  ¶

故障类型		故障处理行为	业务影响
资源耗尽 类故障	磁盘满（数据盘）	资源状态未发生变化，各资源未发生 故障。	1.数据库业务执行失败，日志报错could not write to log file: No space left on device 。 2.磁盘空间充足后，可自动恢复正常。
	磁盘IO高(数据盘)	1.资源状态未发生变化，各资源未发生 故障。 2.可能导致文件系统资源故障重启	1.无影响 2.若文件系统资源故障重启，则在资源故障后到资源恢复 前业务执行失败。
	投票盘IO高	1.资源状态未发生变化，各资源未发生 故障。 2.可能导致文件系统资源故障重启	1.无影响 2.若文件系统资源故障重启，则在资源故障后到资源恢复 前业务执行失败。
	内存使用率高	1.资源状态未发生变化，各资源未发生 故障。 2.可能导致资源故障重启	1.无影响 2.若资源故障重启，则在资源故障后到资源恢复前业务执 行失败。
	cpu利用率高	1.资源状态未发生变化，各资源未发生 故障。 2.可能导致资源故障重启	1.无影响 2.若资源故障重启，则在资源故障后到资源恢复前业务执 行失败。

4.4. 监控指标 ¶

表 4.4.2 监控指标  ¶

参数指标	取值范围	异常范围/级别	获取方式
Pacemaker进程状态	stopped /runing	stopped/错误	/etc/init.d/pacemaker status
Corosync进程状态	stopped/runing	stopped/错误	/etc/init.d/corosync status
Corosync-qdevice 进程状态	Stopped/running	stopped/错误	/etc/init.d/corosync-qdevice status
节点状态	offline, online,standby	offline, standby/错误	crm_mon -1 | grep -E "offline | standby | Online"
资源状态	Failed,started ,starting	failed/错误	crm resouce show | grep failed
查看集 群是否有quorum	Yes/no	no/错误	corosync-quorumtool -s| grep Quorate:
disk模式master_id	0 ——nnodes	0/错误	./corosync-qdevice-tool -sv -p /opt/KingbaseHA /corosync-qdevice/var/run /corosync-qdevice /corosync-qdevice.sock | grep "master id" | awk -F':' '{print $2}'
存储STATE	MOUNTED /UNMOUNTED	>0/错误	crm storage | grep UNMOUNT | wc -l
存储容量	0/1	>0/告警	crm storage | grep -v -e "VOTEDISK\|PATH" | awk '{print ((4/(4/(4 + $5)) > 0.8)}' | grep 1 | wc -l

4.5. 从计划外停机中恢复 ¶

4.5.1. 实例故障、主机/网络故障但存储可用 ¶

在发生实例、主机、网络故障时，clusterware会自动将资源运行到正常的节点并重启故障或是在网络分区时被认为应离开集群的节点。

在修复故障后可以通过重启clusterware将节点加入集群，在推荐配置中没有设置资源的节点偏好，启动clusterware后需要手动移动资源到加入的节点。如果有设置资源的节点偏好，重新加入节点会造成资源的迁移导致服务短暂中断。

1. 启动clusterware

   /etc/init.d/corosync start
   /etc/init.d/corosync-qdevice start
   /etc/init.d/pacemaker start
   

2. 移动资源到重加入的节点

   1. 通过crm_mon确认资源当前运行的节点（假设节点名为节点2）

   2. 移动资源（假设名称为资源1）从节点2到重加入的节点1

   3. 通过crm_mon确认资源正确转移

   4. 清理节点2上的资源移动规则

4.5.2. 存储故障/数据损坏的恢复 ¶

clusterware本身不提供存储支持或数据冗余，故障后clusterware需要从备份恢复配置。

4.5.3. 集群故障或站点故障的恢复 ¶

clusterware本身不提供跨站点或集群的冗余，故障后clusterware需要从备份恢复配置。

4.5.4. FENCE设备故障的恢复 ¶

FENCE设备是保障集群共享资源被正确操作的基础，集群中节点的FENCE设备损坏时该节点再发生其他故障将导致集群试图FENCE该节点而停止其他服务。

恢复方式：

1. 手动处理故障

   1. 手动通过电源开关关闭FENCE设备损坏的节点

   2. 在正常节点上执行stonith_admin -C 故障节点

2. 修复故障的IPMI设备

3. 按照主机故障的恢复方式恢复节点

4.5.5. clusterware备份和恢复方式 ¶

1. 备份

   1. 成员管理：复制corosync.conf配置文件

   2. 资源管理：crm configure save 备份文件

2. 恢复

   1. 恢复软件环境：重新配置系统参数，安装clusterware

   2. 恢复配置：

      1. 成员管理：复制corosync.conf到配置文件位置

      2. 资源管理：crm configure load replace 备份文件

4.6. 计划内停机操作 ¶

补丁、升级

4.6.1. 资源补丁、升级 ¶

clusterware提供的资源支持使用在线替换的方式升级，支持范围见下表：

表 4.6.1 资源补丁、升级  ¶

资源	支持在线替换
Ping	是
Kingbase	是
Filesystem	是
Ipaddr2	是
Sg_persist	是
fence_vmware_soap	是

4.6.2. clusterware补丁、升级 ¶

clusterware组件的升级可使用以下几种方式：

表 4.6.2 clusterware补丁、升级  ¶

	脱管资源	滚动
版本限制	无	不支持 跨版本升级或有通讯协议 升级的情况，需要确认。
升级中服务可用性	服务可用， 只有在升级过程中发生故 障（包括计划内重启主机 ）时会造成服务中断。	升级中每个节点会停 服务一次，两节点分库方 案中会有服务的3次中断。
可用于故障演练	否	是

补丁和升级建议的方式：

在充分测试情况下（参见高可用概述的搭建测试验证环境一节），尽可能申请停机时间使用脱管资源方式升级。

4.6.2.1. 脱管资源方式 ¶

1. 脱管全部资源

   crm_attribute --name maintenance-mode --update true
   

2. 在集群中每个节点执行

   1. 停止clusterware

   2. 完成变更

3. 在集群中每个节点执行：

   1. 启动clusterware

   2. 验证配置确认没有错误和警告

4. 通过crm_mon确认全部资源状态被正确识别

5. 重新管控资源

4.6.2.2. 滚动方式 ¶

在集群中一个节点（假设节点名为节点1）执行：

1. 设置节点为standby状态

crm_standby --node 节点1 -v on

1. 通过crm_mon确认资源都正确转移到其他节点

2. 停止clusterware

/etc/init.d/pacemaker stop
/etc/init.d/corosync-qdevice stop
/etc/init.d/corosync stop

1. 完成变更

2. 启动clusterware

/etc/init.d/corosync start
/etc/init.d/corosync-qdevice start
/etc/init.d/pacemaker start

1. 验证配置确认没有错误和警告

crm_verify --live-check

1. 清除节点standby状态

crm_standby --node 节点1 -v off

如果需要，移动资源到变更后的节点

1. 通过crm_mon确认资源当前运行的节点（假设节点名为节点2）

2. 移动资源（假设名称为资源1）从节点2到变更后的节点1

crm_resource -M 节点1 -r 资源1

1. 通过crm_mon确认资源正确转移

2. 清理节点2上的资源移动规则

crm_resource -U --node 节点2 -r 资源1

1. 在剩余节点上重复执行1、2中的步骤

4.6.3. 系统或硬件补丁、升级 ¶

如果变更需要重启主机或是停止网络等影响资源运行的操作，选择滚动方式，否则选择脱管资源方式。操作方法见clusterware补丁、升级一节。

4.7. 配置变更 ¶

4.7.1. 资源配置 ¶

1. 对资源参数的修改不会造成服务中断。

2. 修改会影响资源运行位置的参数会造成资源迁移，导致服务短时间中断，需要申请停机时间。

4.7.2. 成员配置 ¶

1. 不包括变更成员数量的配置变更。

2. 修改需要重启clusterware，建议使用脱管资源方式变更配置。

4.7.3. 增加删除节点 ¶

增加删除节点需要同时修改成员配置和资源配置，对配置的更改请咨询产品服务人员。