目录
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可以实现以下几种方案：
使用共享存储的高可用方案
图 4.1.35基于共享存储的高可用方案¶
使用共享存储的高可用多活方案，适用于：
单个应用做了库级的解耦，可以通过分库将压力分散到不同数据库实例。以下是逻辑图示，正常运行情况和单个节点故障的情况：
图 4.1.36单个应用做库级的解耦¶
多个应用的集约化部署，每个应用使用单个数据库实例。以下是逻辑图示，正常运行情况和单个节点故障的情况：
图 4.1.37多个应用的集约化部署¶
这些高可用方案和读写分离集群方案的选择和比较请参考KingbaseES高可用概述中“功能相近特性的选择”一节。
4.2.配置¶
数据库集群件Clusterware是一个复杂的系统，涉及多个数据库，多个主机，多种资源，多种配置，在用户现场部署运行数据库集群件是一个较为复杂、困难的事情。特编写该文档，对实施在现场部署集群件起到一个规范和指导的作用。本章节分为四部分，第一部分介绍集群部署相关配置，第二部分介绍故障处理行为，第三部分介绍监控指标，第四部分介绍从计划外停机中恢复，第五部分介绍计划内停机操作，第六部分介绍配置变更。
4.2.1.硬件配置¶
4.2.1.1.限制¶
4.2.1.2.推荐配置¶
两节点分库方案中共享存储设备需要分成三个LUN，第一个LUN大小100M，作为投票盘，其他两个LUN作为分库的数据存储区域。
4.2.2.操作系统配置¶
和KingbaseES的操作系统配置要求相同。 特别的：建议配置NTP时钟同步。
4.2.2.1.配置NTP实现时间同步¶
环境中有时间服务器的情况下各节点同步时间服务器
如果时间服务器端有客户端IP限制，加入各节点IP
各节点在ntp.conf中加入时间服务器配置（以192.168.4.134为例）
server 192.168.4.134 preferfudge 192.168.4.134 stratum 10
环境中没有时间服务器的情况下设置集群中一个节点为NTP服务器，其他节点向此服务器同步时间。使用此种方式时要注意在NTP服务器节点故障修复后重新加入网络时需要手动检查系统时间，可以设置为比运行节点中时间最快的更快几秒。
NTP服务器节点在ntp.conf中加入向本地时间同步设置（以192.168.4.1为子网IP，以255.255.255.0为子网掩码为例）
server 127.127.1.0 preferfudge 127.127.1.0 stratum 10restrict 192.168.4.1 mask 255.255.255.0
NTP客户端各节点在ntp.conf中加入时间服务器配置（以192.168.4.134为例）
server 192.168.4.134 preferfudge 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）配置¶
按以下命令初始化投票盘
mkqdisk -c /dev/设备 -l 自定义名称
查看初始化信息
mkqdisk -f 自定义名称 -d -m
4.2.3.2.成员管理（corosync）配置¶
4.2.3.2.1.说明¶
以下配置无特别说明：
不包括不使用的段
不包括默认的配置值
4.2.3.2.2.TOTEM段¶
4.2.3.2.3.TOTEM.INTERFACE段¶
4.2.3.2.4.NODELIST段¶
4.2.3.2.5.QUORUM & QUORUM.DEVICE段¶
4.2.3.2.6.QUORUM.DEVICE.DISK段¶
4.2.3.2.7.LOGGING段¶
4.2.3.2.8.SYSTEM段¶
4.2.3.2.9.配置间关系¶
两节点集群中不考虑qdisk的多次故障造成的投票时间增加，单次投票在master io故障情况下到新master选举投票的时间最大为：
interval * (tko + master_wait + upgrade_wait) + fence_timeout
fence_timeout应小于tko * interval避免因fence导致心跳更新不及时。
考虑bid过程中有新节点的恢复，master_wait要比tko_up大。
qdevice的timeout应该大于qdisk单次投票的最大时长避免正常投票过程超时。
qdevice的sync_timeout应该大于timeout。
corosync的totem应该大于qdisk单次投票的最大时长避免投票过程中的节点变更。
4.2.3.2.10.两节点推荐配置¶
配置见corosync_2nodes.conf
4.2.3.2.11.配置调整¶
在推荐配置基础上修改集群节点数、集群名。
在满足配置间关系的情况下，根据现场RTO需求和网络状况调整各个超时参数，实现更小的RTO或是减少异常干扰。
在专用机环境根据策略调整存储位置。
4.2.3.3.资源管理（pacemaker）配置¶
4.2.3.3.1.说明¶
以下配置无特别说明：
不包括默认的配置值。
描述格式使用crm configure形式。
4.2.3.3.2.CLUSTER OPTIONS¶
4.2.3.3.3.资源OPERATION配置¶
Pacemaker的资源代理脚本基本上需要支持stop，start，monitor三种操作，每个操作有如下属性可以配置。
4.2.3.3.4.资源META配置¶
资源meta属性,设置资源的全局属性,无关资源以何种属性运行
为了自动清理资源失败的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
IPMI环境
primitive fence_node1_ipmi stonith:fence_ipmilan \params ipaddr=192.168.2.100 login=Administrator passwd="Admin@9000"pcmk_host_list=node1 lanplus=trueipmitool_path=/opt/KingbaseHA/ipmi_tool/bin/ipmitool \op monitor interval=60s \meta failure-timeout=5min
2）. File System & Storage lock
FileSystem
File SYSTEM资源是一种pacemaker支持的OCF资源，其资源agent脚本位于$OCF_ROOT/resource.d/heartbeat/Filesystem,，主要用于管控文件系统资源，自动将文件系统挂载指定的目录，该脚本提供如下参数：
另外该脚本还支持在监控时，进行深度操作，即OCF_CHECK_LEVEL值的设置，目前支持两个值：
20：往磁盘中可读可写，只有可读可写，文件系统才算正常
10：往磁盘中可读，只要可读，文件系统就算正常。
配置实例：将/dev/sdc的ext4文件系统挂载到/sharedata/data1目录下，需要确保/sharedata/data1目录优先存在。
由于在linux中/dev/sdx是由内核加载硬盘顺序决定的，存在着不确定性，故建议使用UUID挂载磁盘。
使用如下命令查看/dev/sdc 的uuid
blkid /dev/sdc/dev/sdc: UUID="c2db7022-444f-4cbe-b452-0301c2387ffc" TYPE="ext4"
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访问。
该脚本提供的参数如下：
配置实例如下，实现在mount文件系统前先独占存储的LUN防止双挂。
primitive sg sg_persist \params devs="/dev/sdc" reservation_type=3 \op monitor interval=30 timeout=60 \meta failure-timeout=5minms disk_reserve sg \meta master-max=1 notify=true target-role=Masterorder storage-order Mandatory: disk_reserve:promote FILESYSTEM1:startcolocation storage-colocation inf: DB1_GROUP disk_reserve:Master
3）. VIP
VIP是一种ocf类型的资源，其代理脚本在$OCF_ROOT/resource.d/heartbeat/IPaddr2，该资源能提供虚拟IP地址服务。Agent提供的参数如下：
配置实例如下：
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，该脚本提供参数如下：
实例配置：
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,其提供的参数如下：
配置实例如下：
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约束有如下属性：
配置实例如下：
如下实例 配置FIP1 在 node1上运行的分数为1000
crm configure location FIP1-on-node1 FIP1 1000: node1
Order约束能够配置资源启动的顺序，资源不一定在一个节点上启动，其主要有如下属性
配置实例如下：
CLONE-PINED资源必须在DB1_GROUP资源启动之前启动，而CLONE-PINGD资源关闭需在DB2_GROUP停止后。
crm configure order cluster-order1 CLONE-PINGD DB1_GROUP
Colocation 约束能够配置资源的结合性，其属性如下：
配置实例：
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资源的概念。
配置实例：
将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每个节点运行有其特殊性。
配置实例如下：
将PINGD资源 打造成clone资源
crm configure clone CLONE-PINGD PINGD
4.2.3.3.9.两节点双库推荐配置¶
1）. 手动配置
使用Clusterware自带的crm工具，手工配置两节点双库。
添加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=trueipmitool_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=trueipmitool_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: node2crm configure location fence_node2_ipmi-on-node1 fence_node2_ipmi 1000: node1
执行如下命令，添加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
执行如下命令，添加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
执行如下命令，添加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
执行如下命令，添加防止FILESYSTEM1双挂服务。
crm configureprimitive SG1 ocf:heartbeat:sg_persist \params devs="/dev/sdc" reservation_type=3 \op monitor interval=30 timeout=60 \meta failure-timeout=5minms disk_reserve1 SG1 \meta master-max=1 notify=true target-role=Masterorder storage-order Mandatory: disk_reserve1:promote FILESYSTEM1:startcolocation storage-colocation inf: DB1_GROUP disk_reserve1:Master
执行如下命令，添加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
执行如下命令，添加防止FILESYSTEM2双挂服务。
crm configureprimitive SG2 ocf:heartbeat:sg_persist \params devs="/dev/sdd" reservation_type=3 \op monitor interval=30 timeout=60 \meta failure-timeout=5minms disk_reserve2 SG2 \meta master-max=1 notify=true target-role=Masterorder storage-order Mandatory: disk_reserve2:promote FILESYSTEM1:startcolocation storage-colocation inf: DB2_GROUP disk_reserve2:Master
执行如下命令，添加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
执行如下命令，将PIND资源，变成clone资源。
crm configure clone CLONE-PINGD PINGD
执行如下命令，添加一个分库资源，注意/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
执行如下命令，添加另一个分库资源，需要修改相应的/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
执行如下命令，创建DB1组资源。
crm configure group DB1_GROUP FIP1 FILESYSTEM1 DB1
执行如下命令，创建DB2组资源。
crm configure group DB2_GROUP FIP2 FILESYSTEM2 DB2
添加DB1 location约束,多个节点，最好分数不一样。
crm configure location DB1-on-node1 DB1_GROUP 1000: node1crm configure location DB1-on-node2 DB1_GROUP 800: node2
添加DB2 location约束,为了达到负载均衡，DB2资源的在各个节点的分数要和VIP2正好相反。
crm configure location DB2-on-node1 DB2_GROUP 800: node1crm configure location DB2-on-node2 DB2_GROUP 1000: node2
执行如下命令，创建资源约束。
crm configure colocation cluster-colo1 inf: DB1_GROUP CLONE-PINGDcrm configure colocation cluster-colo2 inf: DB2_GROUP CLONE-PINGD
设置资源保留在原节点的分数，如果考虑高可用性，即重启节点，不对资源产生迁移，需确保location约束的分数 + 该分数都大于最大的location得到的分数，如果考虑性能，即资源负载问题，那么需要将该值设置的越小越好。
crm configure rsc_defaults resource-stickiness=500
2）. 配置文件
配置见crm_2nodes.txt
4.2.3.3.10.配置调整¶
根据现场环境，调整上述环境参数的值，主要涉及具体环境。
根据现场环境，调整各个资源的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设置为上述执行时间的两倍。
根据高可用性，调整资源迁移分数，来达到高可用与负载均衡的平衡。
4.3.故障处理行为¶
在使用以上配置时的故障处理行为如下，故障的恢复请参考从计划外停机中恢复一节的内容。
4.3.1.网络类故障¶
4.3.2.状态变化类故障¶
注意
目前资源的stop操作on-fail设置是fence，如果进程的hang导致资源的stop无法完成会导致节点被fence，即使已经没有其他可用节点。
4.3.3.资源耗尽类故障¶
4.4.监控指标¶
4.5.从计划外停机中恢复¶
4.5.1.实例故障、主机/网络故障但存储可用¶
在发生实例、主机、网络故障时，clusterware会自动将资源运行到正常的节点并重启故障或是在网络分区时被认为应离开集群的节点。
在修复故障后可以通过重启clusterware将节点加入集群，在推荐配置中没有设置资源的节点偏好，启动clusterware后需要手动移动资源到加入的节点。如果有设置资源的节点偏好，重新加入节点会造成资源的迁移导致服务短暂中断。
启动clusterware
/etc/init.d/corosync start/etc/init.d/corosync-qdevice start/etc/init.d/pacemaker start
移动资源到重加入的节点
通过crm_mon确认资源当前运行的节点（假设节点名为节点2）
移动资源（假设名称为资源1）从节点2到重加入的节点1
通过crm_mon确认资源正确转移
清理节点2上的资源移动规则
4.5.2.存储故障/数据损坏的恢复¶
clusterware本身不提供存储支持或数据冗余，故障后clusterware需要从备份恢复配置。
4.5.3.集群故障或站点故障的恢复¶
clusterware本身不提供跨站点或集群的冗余，故障后clusterware需要从备份恢复配置。
4.5.4.FENCE设备故障的恢复¶
FENCE设备是保障集群共享资源被正确操作的基础，集群中节点的FENCE设备损坏时该节点再发生其他故障将导致集群试图FENCE该节点而停止其他服务。
恢复方式：
手动处理故障
手动通过电源开关关闭FENCE设备损坏的节点
在正常节点上执行stonith_admin -C 故障节点
修复故障的IPMI设备
按照主机故障的恢复方式恢复节点
4.5.5.clusterware备份和恢复方式¶
备份
成员管理：复制corosync.conf配置文件
资源管理：crm configure save 备份文件
恢复
恢复软件环境：重新配置系统参数，安装clusterware
恢复配置：
成员管理：复制corosync.conf到配置文件位置
资源管理：crm configure load replace 备份文件
4.6.计划内停机操作¶
补丁、升级
4.6.1.资源补丁、升级¶
clusterware提供的资源支持使用在线替换的方式升级，支持范围见下表：
4.6.2.clusterware补丁、升级¶
clusterware组件的升级可使用以下几种方式：
补丁和升级建议的方式：
在充分测试情况下（参见高可用概述的搭建测试验证环境一节），尽可能申请停机时间使用脱管资源方式升级。
4.6.2.1.脱管资源方式¶
脱管全部资源
crm_attribute --name maintenance-mode --update true
在集群中每个节点执行
停止clusterware
完成变更
在集群中每个节点执行：
启动clusterware
验证配置确认没有错误和警告
通过crm_mon确认全部资源状态被正确识别
重新管控资源
4.6.2.2.滚动方式¶
在集群中一个节点（假设节点名为节点1）执行：
设置节点为standby状态
crm_standby --node 节点1 -v on
通过crm_mon确认资源都正确转移到其他节点
停止clusterware
/etc/init.d/pacemaker stop/etc/init.d/corosync-qdevice stop/etc/init.d/corosync stop
完成变更
启动clusterware
/etc/init.d/corosync start/etc/init.d/corosync-qdevice start/etc/init.d/pacemaker start
验证配置确认没有错误和警告
crm_verify --live-check
清除节点standby状态
crm_standby --node 节点1 -v off
如果需要，移动资源到变更后的节点
通过crm_mon确认资源当前运行的节点（假设节点名为节点2）
移动资源（假设名称为资源1）从节点2到变更后的节点1
crm_resource -M 节点1 -r 资源1
通过crm_mon确认资源正确转移
清理节点2上的资源移动规则
crm_resource -U --node 节点2 -r 资源1
在剩余节点上重复执行1、2中的步骤
4.6.3.系统或硬件补丁、升级¶
如果变更需要重启主机或是停止网络等影响资源运行的操作，选择滚动方式，否则选择脱管资源方式。操作方法见clusterware补丁、升级一节。
4.7.配置变更¶
4.7.1.资源配置¶
对资源参数的修改不会造成服务中断。
修改会影响资源运行位置的参数会造成资源迁移，导致服务短时间中断，需要申请停机时间。
4.7.2.成员配置¶
不包括变更成员数量的配置变更。
修改需要重启clusterware，建议使用脱管资源方式变更配置。
4.7.3.增加删除节点¶
增加删除节点需要同时修改成员配置和资源配置，对配置的更改请咨询产品服务人员。
如果觉得《金仓数据库KingbaseES高可用最佳应用实践（Clusterware）》对你有帮助，请点赞、收藏，并留下你的观点哦！
