KingbaseES高可用最佳应用实践.pdf

KingbaseES 高可用最佳应用实践 金仓数据库管理系统 KingbaseES 文档版本：V9（V009R001C001B0024） 发布日期：2023 年 10 月 12 日 北京人大金仓信息技术股份有限公司 目 目 录 录 第 1 章 前言 1 1.1 适用读者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 相关文档 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 术语 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 手册约定 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 2 章 KingbaseES 单机 4 2.1 KingbaseES 单机简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 硬件配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1.1 限制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1.2 推荐配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 操作系统配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 单机数据库配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3.1 数据库配置文件 kingbase.conf 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3.2 数据库配置文件 sys_hba.conf 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.3.3 数据库自动启动服务配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 2.3 监控指标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 从计划外停机中恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 计划内停机操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.1.1 kingbase 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.1.2 系统或硬件补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 配置变更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 配置文件修改 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.1 2.5.2 2.5.2.1 第 3 章 KingbaseES 读写分离集群 13 3.1 KingbaseES 读写分离集群简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 硬件配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 限制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1 3.2.1.1 I 目 录 推荐配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2 操作系统配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3 集群配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3.1 数据库自动启动服务配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3.2 数据库配置文件 es_rep.conf 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3.3 集群配置文件 repmgr.conf 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.3.4 集群配置参数与切换时间的关系 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 JDBC 读写分离配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.4.1 简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.4.2 设置配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3 故障处理行为 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4 监控指标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.5 从计划外停机中恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.5.1 站点故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.5.2 实例或计算机故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.5.3 存储故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5.4 数据损坏/人为错误 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5.5 响应慢或挂起 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5.6 脑裂后处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 计划内停机操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.6.1.1 资源补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.6.1.2 repmgr 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.6.1.2.1 停机升级方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.6.1.2.2 在线升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 系统或硬件补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 配置变更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 配置文件修改 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 增加删除节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2.1.2 3.2.4 3.6 3.6.1 3.6.1.3 3.6.2 3.6.2.1 3.6.3 第 4 章 KingbaseES Clusterware 42 4.1 KingbaseES Clusterware 简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 硬件配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.1.1 限制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.1.2 推荐配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 操作系统配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.2.1 配置 NTP 实现时间同步 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.2.2 终端 term 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Clusterware 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.3.1 投票盘（qdevice-disk）配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.3.2 成员管理（corosync）配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.1 4.2.2 4.2.3 II 目 录 4.2.3.2.1 说明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.3.2.2 totem 段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.3.2.3 totem.interface 段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.3.2.4 nodelist 段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.3.2.5 quorum & quorum.device 段 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.3.2.6 quorum.device.disk 段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.3.2.7 logging 段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.3.2.8 system 段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.3.2.9 配置间关系 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.3.2.10 两节点推荐配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.3.2.11 配置调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 资源管理（pacemaker）配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.3.3.1 说明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.3.3.2 Cluster options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.3.3.3 资源 operation 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.3.3.4 资源 meta 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.3.3.5 资源配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.3.3.6 资源约束配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.3.3.7 资源迁移分数配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2.3.3.8 Group 资源与 CLONE 资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.3.3.9 两节点双库推荐配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2.3.3.10 配置调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 故障处理行为 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.3.1 网络类故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.3.2 状态变化类故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3.3 资源耗尽类故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.3.3 4.3 4.4 监控指标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5 从计划外停机中恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.5.1 实例故障、主机/网络故障但存储可用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.5.2 存储故障/数据损坏的恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.5.3 集群故障或站点故障的恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.5.4 FENCE 设备故障的恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.5.5 clusterware 备份和恢复方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 计划内停机操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.6.1 资源补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.6.2 clusterware 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.6.2.1 脱管资源方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.6.2.2 滚动方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 系统或硬件补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.6 4.6.3 4.7 配置变更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.7.1 资源配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.7.2 成员配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 III 4.7.3 目 录 增加删除节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 第 5 章 KingbaseES 备份恢复 83 5.1 KingbaseES 备份恢复简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2 重要提示信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3 备份方案和适用场景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.1 备份方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.2 适用场景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.2.1 非独立备份单节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.2.2 非独立备份多节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3.2.3 独立备份单节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.2.4 独立备份多节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 制定备份策略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4.1 备份恢复过程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4.2 备份策略制定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.4.3 常用策略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.4 5.5 独立备份 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5.1.1 硬件-限制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5.1.2 硬件-推荐配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.5.1.3 数据库配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.5.1.4 备份还原功能配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.5.2 监控指标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3 从计划外停机中恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3.1 集群还原策略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3.2 站点故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.5.3.3 实例或计算机故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.5.3.4 存储故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.5.3.5 数据损坏/人为错误 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.3.6 响应慢或挂起 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 计划内停机操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.4.1.1 资源补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.4.1.2 sys_rman 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.4.1.3 停机升级方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.4.1.4 在线升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.4.1.5 系统或硬件补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 配置变更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 sys_rman 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 增加删除节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 非独立备份 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.5.1 5.5.4 5.5.4.1 5.5.4.2 5.5.4.2.1 5.5.4.3 5.6 5.6.1 IV 目 录 5.6.1.1 硬件-限制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.6.1.2 硬件-推荐配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.6.1.3 数据库配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.6.1.4 备份还原功能配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.6.2 监控指标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.6.3 从计划外停机中恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.6.4 5.6.3.1 集群还原策略 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.6.3.2 站点故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.6.3.3 实例或计算机故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.6.3.4 存储故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.6.3.5 数据损坏/人为错误 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.6.3.6 响应慢或挂起 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 计划内停机操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.6.4.1 5.6.4.2 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.6.4.1.1 资源补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.6.4.1.2 sys_rman 补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.6.4.1.3 停机升级方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.6.4.1.4 在线升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.6.4.1.5 系统或硬件补丁、升级 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 配置变更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.6.4.2.1 5.6.4.3 sys_rman 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 增加删除节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 第 6 章 KingbaseES 在线数据定义变更特性 107 版权声明 108 服务周期承诺 109 V 第 1 章 前言 1 第 章 前言 本文描述了 KingbaseES 以及 KingbaseES 高可用集群最佳应用实践。 前言部分包含以下主题： • 适用读者 • 相关文档 • 术语 • 手册约定 1.1 适用读者 KingbaseES 高可用最佳应用实践面向所有使用 KingbaseES 的用户，主要是数据库管理员和应用程序开发人员。 1.2 相关文档 有关高可用最佳应用实践的关联技术的更多信息，请参阅以下资源： • 有关高可用概念，原理，架构、特性的更多信息，请参阅《高可用概述》 • 有关物理备份恢复的更多信息，请参阅《KingbaseES 物理备份恢复最佳实践》 • 有关数据库集群故障、数据异常（损坏或丢失) 恢复实践的更多信息，请参阅《KingbaseES 高可用常见故障恢 复指南》 1.3 术语 1 第 1 章 前言 术语 定义 金 仓 数 据 库 管 理 系 统 （King- 人大金仓数据库管理系统，本文指代单机服务版本，下文也被称作单机版。其成 baseES） 员可能包括数据节点（data node）、备份节点（repo node）。 金仓数据守护集群软件 金仓数据守护集群软件用于构建基于流复制技术实现数据同步的主备数据库集 （Kingbase Data Watch） 群。该类集群由主库、备库和守护进程组成，其中主库提供数据库读写服务，备 库作为主库的备份，守护进程负责检查各库及环境状态并实现自动故障转移。基 于该软件，用户可构建同机房内、同城、异地的容灾及可用性方案，确保各种故 障及灾害时的用户数据及数据库服务安全与连续。 金仓数据库读写分离集群软件 金仓数据库读写分离集群软件在金仓数据守护集群软件的基础上增加了对应用透 （KingbaseRWC） 明的读写负载均衡能力。相比数据守护集群，该类集群中所有备库均可对外提供 查询能力，从而减轻了主库的读负载压力，可实现更高的事务吞吐率；该软件支 持在多个备库间进行读负载均衡。 其成员可能包括主节点（primary node）、备节点（standby node）、辅助节点 （witness node）、备份节点（repo node）。 金仓 KingbaseRAC 集群数据 金仓 KingbaseRAC 集群数据库软件用于构建采用共享存储架构的对等多写数据 库软件（KingbaseRAC） 库集群，该软件通过缓存交换技术保持各个节点的一致性。该类集群具有对应用 透明、高可用、高性能扩展、低存储成本等特点，可满足绝大多数应用场景的功 能、性能、可用性要求。 金 仓 高 可 用 软 件 （King- 以“保障企业级关键业务不间断运行”为目标，为用户提供 Linux 平台上完整的 baseHA） 数据库高可用性解决方案，减少由计算机硬件或软件出现故障所带来的损失。当 集群中的某个节点由于软件或硬件原因发生故障时，集群系统可以把 IP 地址、 业务应用等服务资源切换到其他健康的节点上，使整个系统能连续不间断地对外 提供服务，从而为企业关键业务提供持续可靠的保障，实现系统零宕机的高可用 和可靠性。 金仓集群资源管理软件 (King- 可提供集群成员管理、故障检测、处置调度等功能。可用于构建共享存储集群冷 baseES Clusterware) 备方案，在单机已经满足性能需求的情况下，低成本的增加 KingbaseES 数据库 的可用性。同时，也是金仓 KingbaseRAC 集群数据库软件所依赖的集群管理组 件。 1.4 手册约定 本文档中可能出现“注意、提示、警告、另请参阅”等标志，它们所代表的含义如下： 注意: 用于突出重要/关键信息、最佳实践等。 2 第 1 章 前言 提示: 用于突出小窍门、捷径等。 警告: 用于传递设备或环境安全警示信息，若不避免，可能会导致设备损坏、数据丢失、设备性能降低或其 它不可预知的结果。 另请参阅: 用于突出参考、参阅等。 以下程序代码书写约定适用于本文档： 符号 说明 [] 表示包含一个或多个可选项。不需要输入中括号本身。 {} 表示包含两个以上（含两个）的候选，必须在其中选取一个。不需要输入花括号本身。 | 分割中括号或者花括号中的两个或两个以上选项。不需要输入“|”本身。 ... 表示其之前的元素可以被重复。 斜体 表示占位符或者需要提供特定值的变量。 大写 表示系统提供的元素，以便与用户定义的元素相互区分。除出现在方括号中的元素外，应当按 照顺序逐字输入。当然，部分元素在系统中是大小写不敏感的，因此用户可以根据系统说明以 小写形式输入。 小写 表示由用户提供的元素。 3 第 2 章 KINGBASEES 单机 2 第 章 KingbaseES 单机 本部分包含以下内容： • KingbaseES 单机简介 • 配置 • 监控指标 • 从计划外停机中恢复 • 计划内停机操作 2.1 KingbaseES 单机简介 本章节主要讲述在单数据库实例的场景下，如何通过配置、部署方式等手段达到 KingbaseES MAA（最大可用性 架构）的初级架构要求：能够自动处理简单的软件故障，能够在除了硬件故障外的其他故障场景下保证数据安全。 2.2 配置 2.2.1 硬件配置 2.2.1.1 限制 无 4 第 2 章 KINGBASEES 单机 2.2.1.2 推荐配置 图 2.2.1: 推荐配置 2.2.2 操作系统配置 5 第 2 章 KINGBASEES 单机 表 2.2.1: 操作系统配置 名称 系统 防火墙 资源 检测方式 建议配置和操作 备注 查询防火墙状 关闭 or 添加端口白名单 建议关闭防火墙。 态 or 防火墙已 service firewalld stop 如果用户确认无法关闭防火墙， 开放端口 service iptables stop 那么在防火墙添加数据库白名单 service ufw stop 不同系统命令不同数据库端口默 service fire- walld status firewall-cmd -- 认 54321，根据实际配置调整。 service iptables zone=public --add-port=54321/ 防火墙管理因操作系统不同而 status tcp 有所区别：Centos7 及以后对应 --permanent Centos6 及以前对应 service ufw sta- firewalld; tus iptables; ubuntu 或者 ufw 系统 firewall-cmd -- 对应 ufw; 请根据实际系统进行操 zone=public -- 作。 list-ports SELINUX getenforce 强制性要求 disabled 若为 enable, selinux/ config 修改 / etc/ 若在机器设备不方便 reboot 时， 文 件， 修 改 可以执行 setenforce 0 操作使得当 SELINUX=disabled 重启 OS 前系统生效。随后按建议配置修 改，在下次重启时配置生效。 limit 资源限制 1.ulimit -n 1.65536 强制性要求 2.ulimit -u 2.65536 如果/ etc/ security/ limit.d/ 目录 若小于 65535， 修 改/ etc/ sec urity/limits.conf 文件，添加 下还有其他配置文件，删除它， 否则最终生效的是 /etc/security/ • soft nofile 65536 limit.d/ 目录下的配置文件，而 • hard nofile 65536 不是 /etc/security/limits.conf。 • soft nproc 65536 • hard nproc 65536 • soft core 65536 • hard core 65536 重启会话 信号量内核参 sysctl 数 nel.sem ker- 强制性要求 5010 641280 5010 256 若 小 于 对 应 推 荐 值， 修 改 / sysctl.conf， 添 加 ker- etc/ nel.sem=5010 641280 5010 256 sysctl -p 见续表 6 第 2 章 KINGBASEES 单机 表 2.2.1 – 续表 名称 检测方式 Remove cat / etc/ no 强制性要求 若为 logind.conf temd/ logind.con， 修 改 Re- yes， 修 改 / etc/ sysRe- systemctl 如果操作系统没有 / etc/ sys- temd/ logind.conf 文件则不需修 改。如果 RemoveIPC 参数被 moveIPC=no 然后执行 moveIPC 端口 备注 systemd/ | grep 数据 建议配置和操作 daemon- 注释，则取消注释并设置成 no reload （防止默认为 yes）。 强制性要求 netstat -an 空 库资 | grep -w 如果查询结果不为空，则说明数 源 ”$db_port” | 据库端口已被使用，数据库无法 启动。根据实际情况停止占用数 grep LISTEN 据库端口的进程，或者修改集群 部署时使用的端口。 目录 ls -l 目录不存在 强制性要求 $db_data_path 如果目录已存在，则说明数据库 使用的 data 目录已被占用，数据 库无法初始化。根据实际情况删 除 data 目录, 或者修改数据库使 用的 data 路径。 2.2.3 单机数据库配置 2.2.3.1 数据库配置文件 kingbase.conf 配置 表 2.2.2: 数据库配置文件 kingbase.conf 配置 参数名称 建议值 备注 listen_addresses * wal_keep_segments 512 max_connections 业务高峰期使用的连接数 ×120% 根据用户业务的实际情况调整 max_repared_transactions 业务高峰期使用的连接数 ×120% 和 max_connectioins 保持一致 port 54321 可根据用户需要进行调整 见续表 7 第 2 章 KINGBASEES 单机 表 2.2.2 – 续表 参数名称 建议值 备注 shared_buffers 物理内存的 1/3 实际使用过程中，数据库会使用大 于此值的内存。 wal_log_hints on wal_level replica minimal < replica < logical，开启归 档要求最小为 replica 级别。 archive_mode on 开 启 归 档， 物 理 备 份 要 求 开 启 归 档。开启归档的情况下，可在误操 作或数据损坏的情况下，通过物理 备份和归档进行数据恢复。 archive_command ’test ! -f $archive_dir/%f && cp %p $archive_dir 即归档日志存放路径。 $archive_dir/%f’ 归档路径最好设置为其他磁盘的路 径，可以规避数据盘损坏导致归档 和数据同时丢失。 logging_collector on 开启日志收集功能，数据库运行日 志会记录在数据目录/ sys_log 的目 录中。 log_destination csvlog stderr 或 csvlog 或 syslog 或 eventlog。stderr 和 csvlog 会将数据库 运行日志记录在数据目录下的文件 中，区分是记录的格式不同，csvlog 格式方便被其他软件读取。而另外 两个配置则依赖操作系统，会记录 到操作系统的系统日志中。 timezone PRC 根据用户使用的时区调整 lc_messages en_US.UTF-8 根 据 用 户 需 要， 可 配 置 成 zh_CN.UTF-8（中文） lc_monetary en_US.UTF-8 根 据 用 户 需 要， 可 配 置 成 zh_CN.UTF-8（中文）。 lc_numeric en_US.UTF-8 根 据 用 户 需 要， 可 配 置 成 zh_CN.UTF-8（中文）。 见续表 8 第 2 章 KINGBASEES 单机 表 2.2.2 – 续表 参数名称 建议值 备注 lc_time en_US.UTF-8 根 据 用 户 需 要， 可 配 置 成 zh_CN.UTF-8（中文）。 full_page_writes 2.2.3.2 on 数据库配置文件 sys_hba.conf 配置 表 2.2.3: 数据库配置文件 sys_hba.conf 配置 2.2.3.3 配置行 备注 local all all scram-sha-256 本机认证规则 host all all 0.0.0.0/0 scram-sha-256 其他 OS 连接数据库认证规则 数据库自动启动服务配置 开启数据库自动启动服务： 使用 root 用户在数据库安装目录下执行 rootDeployClusterware.sh 脚本。 $install_dir/install/script/rootDeployClusterware.sh 注意: 以上 install_dir 为所指定的安装目录，例如:”/opt/Kingbase/ES/V9”, 同时需事先将此路径指定给环境变 量 install_dir；否则也可以使用绝对路径执行。 /opt/Kingbase/ES/V9/install/script/rootDeployClusterware.sh 执行后会将安装时初始化的数据库实例注册为系统服务并为其设置开机自动启动，服务开启自动启动只在服务器 级别的重启生效，数据库实例故障后不会自动启动。 服务名称：kingbased 关闭数据库自动启动服务： 停止服务： 9 第 2 章 KINGBASEES 单机 service kingbased stop 关闭服务开机自动启动： Redhat chkconfig --del kingbased Debian update-rc.d -f kingbased remove 2.3 监控指标 表 2.3.1: 监控指标 2.4 参数指标 取值范围 异常范围 获取方式 db 进程状态 stopped/runing stopped $bin/sys_ctl -D $data_path status 从计划外停机中恢复 表 2.4.1: 从计划外停机中恢复 故障类型 恢复方式 实例故障 $bin/sys_ctl -D $data_path restart 主机/网络故障 (存储可用) 网络故障时，数据库实例正常，等待网络恢复即可。 存储故障 1, 数据库备份文件所在存储未故障 恢复方法见章节备份和还原-配置 (单机) 2. 数据库备份文件所在存储故障 数据将丢失 数据损坏 恢复方法见章节备份和还原-配置 (单机) 见续表 10 第 2 章 KINGBASEES 单机 表 2.4.1 – 续表 故障类型 恢复方式 人为错误 根据人为操作造成的影响判断能否成功恢复，如果备份 文件和日志文件完整则可以恢复，恢复方法见章节备份 和还原-配置 (单机)。 站点故障 恢复方法见章节备份和还原-配置 (单机) 响应慢或挂起 通过性能指标监控发现，取决于后续排查和处理速度。 2.5 计划内停机操作 2.5.1 补丁、升级 2.5.1.1 kingbase 补丁、升级 kingbase 升级方式 1 升级后兼容原有数据 备份原 kingbase 可执行程序，替换 kingbase 可执行程序和相关组件，重启数据库。 $bin/sys_ctl -D $data_path restart 2 升级后不兼容原有数据 停止使用数据库的应用，备份数据库和原可执行程序 进 行 实 例 级 逻 辑 备 份， 并 记 录 数 据 库 初 始 化 时 指 定 的 参 数， 无 法 在 初 始 化 后 修 改 的 内 容 包 括： wal_segment_size，database_mode，data_checksums $bin/sys_dumpall -h host -U -p port -f 停止数据库 $bin/sys_ctl -D $data_path stop 清理 data，使用初始化工具按之前的初始化参数重新 initdb data，拷贝配置文件，启动数据库，进行逻辑还原。 $bin/initdb -U username -D $data_path $bin/sys_ctl -D $data_path start 11 第 2 章 KINGBASEES 单机 $bin/ksql -h host -U -W password -d dbname -f 2.5.1.2 系统或硬件补丁、升级 如果变更不需要重启主机或是停止网络等影响数据库运行的操作，选择在线升级，否则选择停机升级。操作方法 见 kingbase 补丁、升级一节。 2.5.2 配置变更 2.5.2.1 配置文件修改 KingbaseES 数据库的配置修改是否需要重启数据库取决于参数 需要重启生效的配置修改需要重启数据库： $bin/sys_ctl -D $data_path restart 不需要重启的配置修改可以通过 reload 生效： $bin/sys_ctl -D $data_path reload 12 第3章 3 第 章 KINGBASEES 读写分离集群 KingbaseES 读写分离集群 本部分包含以下内容： • KingbaseES 读写分离集群简介 • 配置 • 故障处理行为 • 监控指标 • 从计划外停机中恢复 • 计划内停机操作 3.1 KingbaseES 读写分离集群简介 本章节主要讲述在多数据库实例的热备模式下，通过标准化配置（满足最低要求）、特定的部署方式等手段达到 KingbaseES MAA（最大可用性架构）的中级架构要求：满足初级架构要求的基础上，能够处理硬件故障（不能是所 有设备的硬件故障），具有更强的数据保护能力；同时能具有处理复杂故障场景（软硬件、网络等故障）的能力、具 有更短的故障恢复时间，能够保证数据库服务持续对外提供服务。 另外，数据库集群是一个复杂的系统，涉及多个数据库，多个主机，多种配置文件，现场部署数据库集群是一件 相对比较复杂、困难的事情。该文档将对现场部署集群起到一个规范和指导的作用。本手册分为四部分，第一部分介 绍集群部署相关配置，第二部分介绍集群监控指标，第三部分介绍集群从计划外停机中恢复，第四部分介绍计划内停 机操作。 13 第3章 3.2 配置 3.2.1 硬件配置 3.2.1.1 限制 KINGBASEES 读写分离集群 无 3.2.1.2 推荐配置 图 3.2.1: 推荐配置 3.2.2 注意: 操作系统配置 限制：集群中所有节点必须要求做时钟同步，系统时间需保持一致（要求至少误差范围在 2s 以内）；否则， 可能会导致主库的 WAL、快照等数据不能及时回收的影响。 14 第3章 KINGBASEES 读写分离集群 表 3.2.1: 操作系统配置 名称 系统 防火墙 资源 检测方式 建议配置和操作 查询防火墙状 关闭 or 添加端口白名单 态 or 防火墙已 service firewalld stop 最好关闭防火墙 开放端口 service iptables stop 如果用户确认无法关 service ufw stop 闭防火墙，那么在防 service fire- 备注 walld status firewall-cmd -- 火墙添加数据库白名 service iptables zone=public --add-port =54321/ 单不同系统命令不 status tcp 同数据库端口默认 --permanent service ufw sta- 54321， 根 据 实 际 配 tus 置调整。防火墙管理 firewall-cmd -- 因操作系统不同而有 zone=public -- 所区别： centos7 以及以后对应 firewalld; list-ports centos6 以及以前对应 iptables; ubuntu 或者 ufw 系统对应的 ufw; SELINUX getenforce 强制性要求 disabled 若为 enable, 修改 selinux/ config / etc/ 若在机器设备不方便 reboot 时， 文 件， 修 改 可以进行 setenforce 0 操作使得当 然后重启 前系统生效。随后按建议配置修 SELINUX=disabled OS 改，可以使得在下次重启时，再 重新变为 disable。 limit 资源限制 1.ulimit -n 1.65536 强制性要求 2.ulimit -u 2.65536 如果/ etc/ security/ limit.d/ 目录 若小于 65535，修改 / etc/ secu- 下还有其他配置文件，删除它， rity/limits.conf 文件，添加 否则最终生效的是 /etc/security/ * soft nofile 655360 limit.d/目录下的配置文件，而不 * hard nofile 655360 是 /etc/security/limits.conf 其 -n * soft nproc 655360 和-u 的值不得小于 65536 （严格 * hard nproc 655360 要求），但可以继续调大，参见 * soft core 655360 推荐值。 * hard core 655360 * soft memlock 50000000 * hard memlock 50000000 重启会话 见续表 15 第3章 KINGBASEES 读写分离集群 表 3.2.1 – 续表 名称 检测方式 信号量内核参 sysctl 数 nel.sem ker- 建议配置和操作 备注 5010 641280 5010 256 强制性要求 若小于对应推荐值，修改/ etc/ sysctl.conf， 添 加 kernel.sem= 5010 641280 5010 256 然后执行 sysctl -p Remove IPC 强制性要求 cat / etc/ sys- no temd/ logind. 若为 conf temd/ logind.con， 修 改 | grep RemoveIPC yes， 修 改 / etc/ sysRe- systemctl / etc/ sys- temd/ logind.conf 文件则不需修 改。 moveIPC=no 然后执行 如果操作系统没有 daemon- 如果 RemoveIPC 参数被注释， 则取消注释并设置成 no （防止 reload 默认为 yes）。 ssh 选项 1. 小于 5 秒 如果集群不使用 sshd 服务（使 root@ 本机 ip 2.no 用 sys_securecmdd），则不需要 ssh root@ 其他 3.no 修改。 设备 ip 耗时 若耗时大于 5 秒、或者 GSS- 2.cat /etc/ssh/ APIAuthentication 为 yes、或者 sshd_config | UseDNS 为 yes，修改/ etc/ ssh/ grep GSSAPI- sshd_config 文件，设置 GSS- Authentication APIAuthentication=no 3.cat /etc/ssh/ UseDNS=no 1. 测试 ssh sshd_config | grep UseDNS 系统 资源 网络传输参数 1.8388608 读写分离集群需要大量网络传 ’wmem_default 2.16777216 输，加大这些参数值，提升传输 | wmem_max | 3.8388608 性能。 rmem_default 4.16777216 | rmem_max’ 如 果 小 于 这 些 值， 则 修 sysctl -a | egrep 改 sysctl.conf， 增 加： net.core.rmem_default 8388608 = net.core.rmem_max = net.core.wmem_default 16777216 = 8388608 net.core.wmem_max = 16777216 然后执行 sysctl -p 见续表 16 第3章 KINGBASEES 读写分离集群 表 3.2.1 – 续表 名称 网络传输参数 检测方式 建议配置和操作 备注 sysctl -a | egrep 8192 65536 16777216 读写分离集群需要大量网络传 ’tcp_wmem 如 果 小 于 这 些 值， 则 修 输，加大这些参数值，提升传输 改 性能。 | tcp_rmem’ sysctl.conf， 增 加： net.ipv4.tcp_rmem = 8192 = 8192 65536 16777216 net.ipv4.tcp_wmem 87380 16777216 网络传输 tc qdisc show 当 前 生 效 （重 启 会 失 效）：tc 如果出现 ssh/sys_securecmd 心 队列 dev 网卡名称 qdisc replace dev 网卡名称 root 跳超时建议修改网络传输队列类 fq_codel 型; 永 久 生 效 （需 重 启）： 如果队列类型是 pfifo_fast 则有 echo 可能出现此问题。 ” net.core. de- fault_qdisc=fq_codel” » / etc/sysctl.conf systemd service cron/ crond status | 若小于 grep systemd/ Tasks | grep limit 强制性要求 65536 65535， 修 改 / etc/ 保证读写分离集群的守护进程 system.conf， 修 改 kbha 能够被 crontab 调度。调整 或 后，需观察 service crond status DefaultTasksAccounting=no 限制是否取消，若未生效，需重 DefaultTasksMax=65536 修改后执行以下命令 system- ctl daemon-reload ; systemctl daemon-reexec 启 OS。 若查询结果为空，这表示 cron/ crond 服务没有限制，为正常配 置，无需修改。 数据 端口 netstat -an 空 强制性要求 库资 | -w 如果查询结果不为空，则说明数 这里的 $DBPORT 是指数据库监 源 ”$DBPORT” | 据库端口已被使用，数据库无法 听端口，kingbase 默认监听端口 grep LISTEN 启动。根据实际情况停止占用数 是 54321。 grep 据库端口的进程，或者修改集群 部署时使用的端口。 目录 ls -l $KING- 目录不存在 强制性要求 BASE_DATA 如果目录已存在，则说明数据库 $KINGBASE_DATA 是数据库 使用的 data 目录已被占用，数据 实 例 存 放 目 录， 在 运 行 库无法初始化。根据实际情况删 时，该目录必须为空。 initdb 除 data 目录，或者修改集群部署 使用的路径。 见续表 17 第3章 KINGBASEES 读写分离集群 表 3.2.1 – 续表 名称 vip 检 检测方式 ip 查 建议配置和操作 备注 存在 在配置集群 VIP 时需要用到 ip $ipaddr_path/ 如果命令不存在，则说明 ip 命令 命令。在 repmgr.conf 有个条目 ip 不存在，数据库集群无法部署， ipaddr_path 指定 ip 命令所在路 操作系统安装 ip 命令。 径。 ls -l 在无需使用 VIP 的情况下，此项 可以略过。 vip ip addr | grep ping 不通 这里的 $vip 与 repmgr.conf 文件 $vip 如果 vip 能够 ping 通则说明 vip 里的 virtual_ip 条目对应，也就 如果不存在就 已被使用，集群部署时配置其他 是集群的 VIP。 ping $vip ip 作为 vip。 3.2.3 集群配置 3.2.3.1 数据库自动启动服务配置 服务名称：kingbased 需要关闭数据库自动启动服务： 停止服务： service kingbased stop 或 systemctl stop kingbased 关闭服务开机自动启动： #Redhat 或 CentOS 系列操作系统 chkconfig --del kingbased 或 systemctl disable kingbased #Debian 系列操作系统 update-rc.d -f kingbased remove 3.2.3.2 数据库配置文件 es_rep.conf 配置 18 第3章 KINGBASEES 读写分离集群 表 3.2.2: 数据库配置文件 es_rep.conf 配置 参数名称 默认值/建议值 listen_addresses * max_wal_senders 32 备注 如果备机数量大于 16，那么 max_wal_senders 设置为备机数量 ×2。 wal_keep_segments 512 正常情况下 sys_wal 下的最大保存文件个数，大 小计算方式 16MB×512 = 8G 。 hot_standby_feedback on 开启后，备库事务所使用的 wal，主库不会删 除。 max_connections 100 根据用户实际情况调整，最佳配置是用户使用到 的连接数 ×120%，在集群中，max_connections 的值只能修改为更大的值，不能修改为更小的 值。 port 54321 根据用户需要，可以调整。 shared_buffers 512MB 根据部署集群 OS 的内存来调整，最佳配置是内 存的 1/3。 fsync on 数据库一致性保证。建议不要修改。 wal_log_hints on 强制性要求, 运行 sys_rewind 前提，在 node rejoin 时需要。 archive_mode on 建议开启以支持备份，在使用不同备份方案时可 能需要修改为 always 以支持备机独立备份，详见 备份章节。 强制性要求, 开启后，备库可读。 hot_standby on log_destination csvlog timezone PRC 根据用户使用的时区调整 wal_level replica 强制性要求, 部署主备集群至少设置成 replica， 如果需要使用逻辑同步，则需设置成 logical。 lc_messages en_US.UTF-8 根 据 用 户 需 要， 可 配 置 成 zh_CN.UTF-8（中 文）。 lc_monetary en_US.UTF-8 根 据 用 户 需 要， 可 配 置 成 zh_CN.UTF-8（中 文）。 见续表 19 第3章 KINGBASEES 读写分离集群 表 3.2.2 – 续表 参数名称 默认值/建议值 备注 lc_numeric en_US.UTF-8 根 据 用 户 需 要， 可 配 置 成 zh_CN.UTF-8（中 文）。 lc_time 根 据 用 户 需 要， 可 配 置 成 en_US.UTF-8 zh_CN.UTF-8（中 文）。 archive_command ’test ! -f $archive_dir/ $archive_dir 即归档日志存放路径归档模式开启 %f 时，才需配置 archive_command。 && cp %p $archive_dir/%f’ logging_collector on 将操作日志写到 sys_log。建议为 on。 full_page_writes on 强制性要求, 开启该参数可以避免数据坏块，建 议为 on。 synchronous_commit remote_apply 同步参数，off < local < remote_write < on < remote_apply，主备集群设置为 remote_apply 可 以保证数据的强一致性，在备库读取到主库一样 的数据。 至少应该为 on，这样可以保证数据不丢失，低于 此配置，主库故障后，备库可能会丢失数据。 注意: 在集群中，max_connections 的值只能修改为更大的值，不能修改为更小的值。 注意: 如果需要调整 max_wal_size（默认值 1GB），请同时调整 wal_keep_segments 的值。默认设置 wal_keep_segments × wal_segment_size >= 8 × max_wal_size。其中 wal_segment_size 默认为 16MB，可以 在 initdb 时指定参数 --wal-segsize=SIZE 来指定 wal_segment_size 的值，已经初始化的 data，不能修改此参数。 以上配置不能保证数据库故障后一定能够恢复，当数据库长时间故障后，需要自动恢复，wal_keep_segments 的 值需要调整的更大（根据数据库生成日志的速度来调整）。请参考以下公式： 根据现场估算以下值： down_time：单个数据库故障到完成恢复的总时间，一般估算为生产系统中单个节点发生最严重的 故障（特别是硬件故障）需要的恢复时间。 down_wal_size：在 down_time 时间内，主库生成的 wal 日志大小。生成的 wal 大小可以根据平时业务 高峰期间每分钟的数据量来估算。 例如：在 data/sys_wal 目录下执行 ls -l | grep "Oct 14 14:35" | awk 'BEGIN {SUM5=0}{SUM5+=$5} END {print SUM5/1024/1024}'， 20 第3章 KINGBASEES 读写分离集群 可以得到'Oct 14 14:35'这一分钟产生的 wal 大小总和（单位为 MB），然后乘以 down_time 得到总大小。 自动恢复满足条件： max_wal_size / (1 + checkpoint_completion_target) < down_wal_size wal_keep_segments >= 4 × down_wal_size / wal_segment_size 举例 1： 默认情况下，checkpoint_completion_target=0.5，wal_segment_size=16MB，max_wal_size=1GB， wal_keep_segments=512 (512 × 16MB = 8GB)。 那么 down_wal_size 范围为 (682.6M, 2GB]，即，如果主库生成了 2GB wal 日志之后， 故障数据库仍然没有恢复，那么后续故障数据库可能无法恢复了。 转换为时间来说明，如果主库 1 分钟生成 100MB 日志， 故障数据库必须在 down_wal_size / 100MB = 20(分钟) 内恢复，否则，故障数据库可能无法恢复。 举例 2： 如果 checkpoint_completion_target=0.5，wal_segment_size=16MB 不变，期望修改 max_wal_size 和 wal_keep_segments。如果设置 max_wal_size=5GB，则 down_wal_size > max_wal_size/(1 + checkpoint_completion_target)=3413MB， wal_keep_segments >= 4 × down_wal_size / wal_segment_size=853。 那么 max_wal_size=5GB，则 wal_keep_segments=853（或更大的值）。 3.2.3.3 集群配置文件 repmgr.conf 配置 表 3.2.3: 集群配置文件 repmgr.conf 配置 节点基 参数名称 默认值/建议值 备注 use_scmd on 是否使用 sys_securecmdd 作为集群安 本配置 全执行命令的工具。如果设置为 on， 会使用集群自带的 sys_securecmdd 工 具。如果设置为 off，会使用操作系统中 的 sshd 服务。 ha_running_mode DG 集群模式，默认模式为 DG，还可以配 置为 TPTC，即两地三中心。 node_id 1 开始的正整数 节点的 node_id 值不能重复 node_name node1 节点名，使用工具进行配置时，会自动 生成（node+id 序号）。 见续表 21 第3章 KINGBASEES 读写分离集群 表 3.2.3 – 续表 参数名称 默认值/建议值 备注 conninfo ’host=xxx.xxx.xxx.xxx 该节点连接信息。注意：是连接本地节 user=esrep dbname=esrep 点的连接串。 port=54321 con- nect_timeout=10 keepalives=1 keepalives_idle=10 keepalives_interval=1 keepalives_count=3’ 日志设 data_directory $KINGBASE_DATA 本地数据库 data 目录路径 log_level INFO 日 志 级 别 根 据 现 场 情 况 配 置， 一 般 置 情况下配置成 置成 INFO 还以可以配 DEBUG、NOTICE、WARN- ING、ERROR、ALERT、CRIT、 EMERG。 log_file ’$cluster_path/ kingbase/ repmgrd 日志存放路径，$cluster_path 表示集群部署目录。日志文件将通过系 log/hamgr.log 统 logrotate 进行定期清理。 kbha_log_file ’$cluster_path/ kingbase/ log/kbha.log kbha 日志存放路径，$cluster_path 表 示集群部署目录。日志文件将通过系统 logrotate 进行定期清理。 环境设 sys_bindir $sys_bin_path 置 命令选 数据库 bin 目录。Repmgr 某些操作需 要调用数据库命令。 scmd_options 项设置 ’-q -o ConnectTimeout=10 -o sys_securecmd 或 ssh 命令的额外选 StrictHostKeyChecking =no 项，需要配置。 -o ServerAliveInterval=2 -o ServerAliveCountMax=5 -p 8890’ vip 设 virtual_ip xxx.xxx.xxx.xxx/24 置 集群使用的虚拟 ip，根据用户的网络配 置可以设置掩码，默认/24 掩码需要和 网卡 net_device 上的实际掩码一致。 ipaddr_path $ip_path ip 命令所在路径 arping_path $arping_path arping 命令所在路径 见续表 22 第3章 KINGBASEES 读写分离集群 表 3.2.3 – 续表 参数名称 默认值/建议值 备注 vip_add_cmd ’ip addr add $virtual_ip 根据现场环境，如果默认命令不可用， dev 可进行修改。 $net_device label $net_device:3’ ’ip addr del $virtual_ip dev 根据现场环境，如果默认命令不可用， $net_device’ 可进行修改。 ’arping -U $virtual_ip -w 2 -c 根据现场环境，如果默认命令不可用， 2 -I $net_device’ 可进行修改。 net_device $dev 网卡名 vip_timeout 30 备机升主过程中，卸载原主 VIP 失败 vip_del_cmd arping_cmd 后等待时长 s，会再次进行卸载。（reboot 过程中会出现 ping 的通 vip 但连 接不上的情况，启动后 vip 又会被系统 自己卸载）。 check_vip_interval 20 主库或备库检查 VIP 的间隔。主库定期 检查 VIP 是否在本设备上，如果不存在 则添加；备库定期检查 VIP 是否在本设 备上，如果存在则自动卸载。 信任网 trusted_servers 关设置 xxx.xxx.xxx.xxx, 信任 ip，根据现场网络环境配置，一般 xxx.xxx.xxx.xxx 推荐填写网关地址；可以配置多个 ip， 表示多个信任节点的检测。 切换和 ping_path $ping_path ping 命令所在路径 failover automatic 切换时自动的还是手动的？根据用户 监控设 需 要， 可 配 置， 建 议 配 置 置 （自动的）也可以配置成 manual（手 automatic 动）。 failover_need_serve r_alive off 两地三中心集群是否支持跨中心切换？ 根据用户需要，可配置，建议配置 off （不 支 持）， 可 以 配 置 为 none（支 持），或者配置为 any（支持但需要故 障主库中心任一服务器存活），或者配 置为 all（支持需要故障主库中心任意服 务器存活）。 见续表 23 第3章 KINGBASEES 读写分离集群 表 3.2.3 – 续表 参数名称 默认值/建议值 备注 recovery standby 故障节点如何恢复？根据用户需要，可 配置，建议配置 standby（自动恢复故 障备节点），可以配置为 manual（手 动 恢 复）， 也 可 以 配 置 成 automatic （自动恢复所有故障节点）。 priority 0 或正整数 (默认 100) 表示升主时，本机所占权重 0 表示本机 不能自动升主，一般用于性能较差的备 机，此备机只做容灾，不希望它升主。 根据用户各个节点的性能，一般情况下 将性能较好的节点的权重设置大一点， 那么该节点更容易升主选举成功。 connection_check_type 检测数据库是否存活的方式，建议配置 mix 为 mix。用户可选配置如下：ping，尝 试连接并根据数据库是否有反馈判断数 据库状态；connection，和数据库建立 连接并根据成功与否判断数据库状态； query，使用已有的和数据库长连接执 行简单查询并根据结果判断数据库状 态；mix，平时使用 ping，当数据库异 常后，尝试重连的最后一次使用 query 来判断数据库状态。 reconnect_attempts 检测失败时，重试次数，根据用户需要 3 调整。 reconnect_interval 检测失败时，重试间隔时间，根据用户 5 需要调整。 promote_command ’$sys_bindir/ standby repmgr promote -f 执行升主的命令，$etc_path 表示集群 etc 目录路径。 $etc_path/ repmgr.conf’ follow_command ’$sys_bindir/ repmgr standby follow -f $etc_path/ 备机执行 follow，跟随新主机的命令 $etc_path 表示集群 etc 目录路径。 repmgr.conf’ monitoring_histroy no 每次监控检测的结果写入数据库表中 monitor_interval_secs 2 每次监控检测间隔时间 见续表 24 第3章 KINGBASEES 读写分离集群 表 3.2.3 – 续表 参数名称 默认值/建议值 repmgrd_pid_file ’$cluster_path/ 备注 kingbase/ repmgrd pid 存放路径 (不要修改此 参数) $cluster_path 表示集群部署目 etc/hamgrd.pid’ 录 repmgrd 进程默认每隔 10×monitor_interval_secs 秒检查此文件和文件 中保存的 pid，如果文件不存在或文件 中保存的 pid 和自己的 pid 不一样， repmgrd 进程会自动退出。 kbha_pid_file ’$cluster_path/ etc/kbha.pid’ kingbase/ kbha pid 存放路径 (不要修改此参 数) $cluster_path 录 kbha 表示集群部署目 进程默认每隔 10×moni- tor_interval_secs 秒检查此文件和文件 中保存的 pid，如果文件不存在或文件 中保存的 pid 和自己的 pid 不一样， kbha 进程会自动退出。 standby_disconnect true 掉流复制时切断流复制后再实施切换。 _on_failover auto_cluster_recovery 备机切换前检查流复制状态，在没有断 1 在集群全部节点故障时尝试进行集群恢 复，在节点间网络正常且集群只有一个 _level 主节点时可恢复集群。 lsn_lag_threshold 16 备库与主库 lsn 差 距 的 阈 值， 单 位 MB，当发生主库故障时，如备库与主 库 lsn 差距超过此值时，若集群配置为 异步流复制则备库不会升主；若配置为 同步模式，只有 1 主多备集群中，出现 主库和备库同时故障，剩余备库会依据 lsn 差距是否超过此阈值判断是否允许 切换。 流复制 synchronous quorum 根据用户需要可配置为 async(异步集 同异步 群) sync(同步集群) quorum(优选同步集 设置 群) all(动态全同步集群) sync_in_same_location 0 两地三中心集群同异步配置的生效范 围。根据用户需要可配置为 0（无限 制），或者 1（同异步参数仅影响主库 所在中心的备库）。 见续表 25 第3章 KINGBASEES 读写分离集群 表 3.2.3 – 续表 磁盘检 参数名称 默认值/建议值 备注 mount_point_dir_list ’$data_directory’ 配置路径，可以配置多个，默认为 data 测设置 目录路径。集群会检测该路径下的读写 是否正常。 mount_check_max_retries 磁盘检测失败时，会重复检测，最大失 6 败检测次数。 use_check_disk 磁盘检测失败达到最大次数后，是否关 on 闭数据库。on 表示开启此功能，关闭数 据库 off 表示关闭此功能，仅报 warning。 注意: recovery 参数设置为 manual 时，主机和备机节点故障后都不会进行自动恢复。recovery 参数设置为 standby 时，仅备机节点故障后会进行自动恢复。 警告: 集群部署完成后，请不要修改 repmgrd_pid_file、kbha_pid_file 参数的值，修改后可能会造成同时 启动多个 kbha 或 repmgrd 进程。 3.2.3.4 集群配置参数与切换时间的关系 表 3.2.4: 集群配置参数与切换时间的关系 正常切换 时间参数 影响切换时间参数 说明 reconnect_attempts 检测到主库失联后重试连接次数 reconnect_interval 检测到主库失联后重试连接间隔 monitor_interval_secs repmgr 监控循环中每次监控间隔 standby_disconnect_on_failover 打开时会增加切断流复制的时间，最佳情况需要 6s。 见续表 26 第3章 KINGBASEES 读写分离集群 表 3.2.4 – 续表 异常情况 影响切换时间参数 说明 trusted_servers 切换时会向配置的 server 执行 ping 操作， 异常情况 ping 不通时会增加重试超时 re- connect_attempts*(reconnect_interval+ping 操 作 timeout）。 在备机提升获取 vip 操作时，需要检查 vip 是 vip_timeout 否仍然存在于原主机，若存在，需要尝试解除， vip_timeout 为尝试接触操作的时间阈值。 conninfo 中的 keepalives, 在网络异常时如出现网络延迟或网络抖动，监控 keepalives_interval, 中连接重连会出现超时情况，包括连接超时和 connect_timeout, keepalives_idle, keepalives_count socket 无响应超时。 scmd_options 中的 ConnectTimeout, Server- 网络异常时，切换过程中可能出现的 ssh 或 AliveInterval, ServerAliveCountMax sys_securecmd 超时，包括连接超时和 socket 无 响应超时。 切换时间估算公式： 网络中断、主机宕机、停库、断电、重启的情况： monitor_interval_secs+reconnect_attempts × reconnect_interval+6+X 注：X 包括 ping trusted_servers, 解除原主 vip、挂载 vip 等操作的时间。 网络抖动的等异常情况的切换： 在网络异常的情况下，无法用上述公式得到确定的切换时间，其值只作为基础值，还需要增加可能出现的网络超 时、重试的时间。 3.2.4 JDBC 读写分离配置 3.2.4.1 简介 JDBC 驱动提供对应用透明的读写分离功能，让应用无成本的快速迁移到数据库读写分离集群，提升整体处理能 力。 3.2.4.2 设置配置 配置支持连接串和配置文件两种形式，读写分离功能参数较多，推荐使用 JDBC 配置文件。 示例： 27 第3章 KINGBASEES 读写分离集群 一主两备环境 主机：192.168.2.129:10001 对应节点名：node1 备机 1：192.168.2.129:10002 对应节点名：node2 备机 2：192.168.2.129:10003 对应节点名：node3 请注意，当数据库部署环境是容器虚拟环境时，配置给 JDBC 的数据库地址应该是运行环境可以访问的地址。 连接串内容 jdbc:kingbase8://192.168.2.129:10001/TEST?ConfigurePath=jdbc.conf 或者简化为： jdbc:kingbase8:TEST?ConfigurePath=jdbc.conf ConfigurePath 指定 jdbc 的配置文件名字，可以带全路径，也可以不带，不带路径时就是 JVM 的 user.dir 目 录。 配置文件内容 HOST=192.168.2.129 PORT=10001 DBNAME=TEST user=SYSTEM password=123456 loggerLevel=OFF loggerFile=jdbc_test.log # 是否使用读写分离功能 USEDISPATCH=true # 主机读负载率 HOSTLOADRATE=50 # 备机地址, 使用逗号分割 SLAVE_ADD=192.168.2.129,192.168.2.129 SLAVE_PORT=10002,10003 #nodeList 指定各节点的名称， # 各节点的名称为./repmgr cluster show 命令查询出的 Name 字段。 # 要求开启读写分离时必须配置此项， # 不允许为空并要与节点的地址配置顺序完全一致。 # 各个节点名称之间用逗号分隔，如：nodeList=node1,node2,node3。 nodeList=node1,node2,node3 # 在新建连接时检查当前连接 DB 是不是 Master, 如果不是回去 slave # 检查有没有 Master, 如果还是找不到 Master 就会向上报错 MASTER_CHECK=true 28 第3章 KINGBASEES 读写分离集群 # 失败重发的最高次数 RETRYTIMES=20 # 失败重发每次的间隔时间（单位：秒） RETRYINTERVAL=5 # 开启集群备机监测线程定时监测集群备机状态 CLUSTER_MONITOR=true # 监测线程每次监测的间隔时间（单位：秒） MONITORINTERVAL=5 3.3 故障处理行为 表 3.3.1: 故障处理行为 故障类型 故障处理行为 影响 集群主库停库 1. 备库 repmgr 尝试重连主节点重连次 备库 repmgr 尝试重连主库阶段业务中 换类故 数和间隔时长可配，默认 6×10s 后备库 断，自动切换完成后恢复。 障 竞选出新主节点实现自动切换 2. 若启用 状态变 自动恢复功能，新主节点会尝试恢复停 库节点。 集群主库节点掉电 备库 repmgr 尝试重连主节点重连次数 同上 和间隔时长可配，默认 6×10s 后备库竞 选出新主节点实现自动切换。 集群主库节点重启 1. 备库 repmgr 尝试重连主节点重连次 同上 数和间隔时长可配，默认 6×10s 后备库 竞选出新主节点实现自动切换 2. 节点重 启后，若启用自动恢复功能，新主节点 会尝试恢复此节点。 集群主库节点系统 同主库停库 同主库停库 崩溃 集群主 repmgrd 由 kbha 负责监控，循环拉起，周期约 5 库节点 进程被 杀死 故障期间不会触发恢复 秒。 kbha 由 crond 负责拉起，1 分钟执行一次。 kingbase 同主库停库 故障期间不会触发集群自启动 同主库停库 见续表 29 第3章 KINGBASEES 读写分离集群 表 3.3.1 – 续表 故障类型 集群主 库节点 进 程 hang 住 故障处理行为 影响 repmgrd 无操作 hang 住期间失去高可用性 无操作 hang 住期间失去高可用性 kbha kingbase 会判定主库故障，备库会升主，而原主 多主 库不能接收到任何操作。 集群备库停库、掉 若启用自动恢复功能，主节点会尝试恢 无业务影响，为不影响业务备库故障可 电或断网 复此节点。 能触发同步流复制转异步。 集群备 repmgrd 由 kbha 负责监控，循环拉起，周期约 5 库节点 进程被 杀死 集群备 库节点 进 程 hang 住 故障期间不会触发切换 秒。 kbha 由 crond 负责拉起，1 分钟执行一次。 故障期间不会触发集群自启动 kingbase 同备库停库 同备库停库 repmgrd 无操作 hang 住期间失去高可用性 无操作 hang 住期间失去高可用性 kbha kingbase 同备库停库 同备库停库 系统时间跳变 无操作 无影响 网络 主节点防火墙误开 同主库停库 该节点新建连接失败 类型故 启 集群主节点网络中 备库 repmgr 尝试重连主节点重连次数 同主库停库 断 和间隔时长可配，默认 6×10s 后备库竞 障 选出新主节点实现自动切换。 网络丢 包 10% 无影响 30% 无影响 60% 可能会触发切换等行为，但各种行为无 集群整体无法提供服务 法互相通知到对方，即使不发生任何行 为，集群也处于一个异常状态，无法正 常提供服务。 网络延 时 1 在 retry × delay 容错范围内即可 无影响 3 5 见续表 30 第3章 KINGBASEES 读写分离集群 表 3.3.1 – 续表 故障类型 网络分 区 1:1 1:2 1:1:1 网关失联 故障处理行为 影响 此网路分区的前提是同时还 ping 的通网 多主 关，备库无法连接主库，在没有仲裁节 点的参与时，备库认为自己还活着，升 主。 所有节点 ping 信任网关失败后，认为网 无影响 关失联，会关闭 repmgrd 进程，集群失 去自动故障切换等 高可用能力，数据库服务不 受影响。 资源 耗尽 类 故障 磁盘满（数据盘） 内核实现，有可能会出现 core 问题。 可能无法恢复集群，需人工介入。 磁盘 IO 高（数据 无操作 响应低 内存使用率高 无操作 无影响 CPU 使用率高 无操作 响应低 连接满 无操作 新建连接无法连接，应用报错。 主库存储故障 repmgr 判定主库存储目录读写失效， 切换完成之前业务中断 盘） 若 use_check_disk 参数开启，则实施 停库操作，备库识别到主库失联，实施 切换。 备库存储故障 备库的 repmgr 判定本节点数据目录 同步改为异步之前数据库不可写 读写失效，若 use_check_disk 参数开 启，则实施停库操作，主库 repmgr 识 别到备库失效后，若为同步流复制，改 为异步。 3.4 监控指标 31 第3章 KINGBASEES 读写分离集群 表 3.4.1: 监控指标 参数指标 取值范围 异常范围 获取方式 节点运行状态状态 ?unreachable ?unreachable $bin/repmgr cluster show -failed -failed !failed !failed ?rejected ?rejected ?running ?running !running !running !running as primary !running as primary !running as standby !running as standby !unknown !unknown ?unknown node type ?unknown node type *running|running 节点主备状态 primary|standby 全节点 standby 双主 $bin/repmgr cluster show db 进程状态 stopped|runing stopped $bin/sys_ctl -D $data_path status sys_securecmdd 进程状态 stopped|running stopped sys_HAscmdd.sh status repmgrd 进程状态 stopped|running stopped $bin/repmgr service status 流复制状态 N/A 缺少备机的信息或 主机 db 执行 sql select * from state 不是 streaming sys_stat_replication; kbha 进程状态 stopped|running stopped ps -ef | grep kbha 复制延迟 0 或小于 10 大于 10 在 standby 端执行以下 sql 获取 当前 standby 的延迟：select case when sys_last_wal_receive_lsn() = sys_last_wal_replay_lsn() then 0 else EX- TRACT(EPOCH FROM now() sys_last_xact_replay_timestamp()) end as replication_lag; 32 第3章 3.5 从计划外停机中恢复 3.5.1 站点故障 KINGBASEES 读写分离集群 站点故障包括网络原因、电力中断或人为原因导致站点设备停止工作，若没有跨站点的备节点，需要人工恢复集 群 集群所有节点发生进程故障、设备断电、设备重启、网络故障 切换：当所有节点同时故障时，无法再通过故障转移的方式继续提供服务。 恢复：在站点故障情况，有可能发生脑裂，在启动之前，必须先进行判断。 1. 通过查看所有节点 data 目录下是否存在 standby.signal 文件来判断集群是否只有一个 primary。 2. 如果只有一个 primary，用 sys_monitor.sh start 启动，启动后通过 repmgr cluster show 确认节点状况，如果所有节点正常，就无需进行后续操作。 3. 如果有多个 primary，需判断哪个节点数据最新；具体方法见脑裂后处理 一节。 注意：在确认哪个 primary 数据最新之前，建议不要启动应用。 对于多个 primary 的场景，sys_monitor.sh 脚本会在启动完所有节点的数据库后停止，集群没有 VIP，也不会有 monitor_exporter 进程。这种情况下，需要人为介入，手工恢复集群。具体过程中如下： 1. 在当前接管的 primary 节点运行 repmgr primary unregister --node-id n ，剔除异常的 primary 节点； 2. 在当前接管的 primary 节点重新运行 sys_monitor.sh start 恢复集群数据库，确保应用先能正常通过 VIP 访问 数据库； 3. 在异常的节点运行 repmgr node rejoin 或 repmgr standby clone，将异常节点重新加入集群。 命令： $bin/sys_monitor.sh start 故障后出现多个主节点的恢复： 如果存在多个主节点（多个节点的 data 目录都不存在 standby.signal 文件，这种情况多是在宕机前，primary 异 常，已进行 standby 切换） 处理策略 1：以最新提升主节点（最新数据）为优先级设置未来主节点 • 通常后切换为主的节点获得了 VIP，将获得更新的数据，查看各个主节点的时间线 (data 目录下 sys_wal)，时 间线高的节点为最新提升的主节点，将其确立为主节点。若时间线相同，比较其节点 LSN，LSN 更高的作为未 来主节点。 • 首先备份其它主节点数据，并停库。 • 在其他主节点上执行 rejoin 操作，重归集群。 33 第3章 KINGBASEES 读写分离集群 处理策略 2：以原有主节点为未来主节点 判断各个主节点中的 timeline，挑选更低的节点为集群主库。 • 由于无法通过从更低时间线执行 rewind 操作，可备份其他主节点 data 目录后，删除 data 目录，直接通过 standby clone 命令重做备库。 standby clone 命令： $bin/repmgr -h host -U username -d dbname -p port standby clone -F --fast-checkpoint 启动数据库： $bin/sys_ctl -D $data_path start 注册成为集群备机： $bin/repmgr standby register -F 若存在跨站点的异地备机，也可以选择手动切换异地备节点为主节点 切换： 跨区域部署的异地备节点不会自主提升为主节点，在主节点发生故障或者人为需要切换时需要手动执行切换操 作。 切换方式： 若主节点已经失效，希望将异地备机提升为主节点。 $bin/repmgr standby promote 恢复： 如果将原来主节点恢复为备节点，可以手动在原主节点上执行命令。 手动恢复命令： $bin/repmgr -h host -U username -d dbname -p port node rejoin --force-rewind 如果希望原来主节点恢复后仍然作为主节点，则需要在执行上述恢复之后再执行一次手动切换动作。 手动切回命令： $bin/repmgr standby switchover 3.5.2 实例或计算机故障 集群主节点发生进程故障、设备断电、设备重启、网络故障 34 第3章 KINGBASEES 读写分离集群 切换： 当集群主机发生进程故障、设备断电、设备重启、网络故障，备机的 repmgrd 监控进程会尝试多次（配置参 数 reconnect_attempts）连接主节点，如果多次连接还是不成功，则 repmgrd 会认为主节点出现故障，开始进行 failover。备节点 failover 过程中，系统会根据 LSN、priority、Node_id 选举一个备节点提升为新主节点，该过程 中，Virtual IP 也会漂移到新主节点，其他备节点运行 follow_command 去 Follow 新主节点。 恢复： 在完成 failover 过程后，如果原来主节点恢复，则系统会有“两个主节点”，repmgrd 守护进程需要对原来主节 点进行降级成备节点，然后重新加入集群。这个过程有两种方式： 自动：repmgr.conf 中如果 recovery 参数值设置为 automatic，主节点恢复后，repmgrd 守护进程会将原来主节 点进行降级成备节点，然后重新加入集群。如果 recovery 参数值设置为 standby，不会对原主节点做任何操作。 手动：repmgr.conf 中 recovery 参数值设置为 manual。在原来的主节点恢复后，需要先停库，再执行手动恢复命 令。 手动恢复命令： $bin/repmgr -h host -U username -d dbname -p port node rejoin --force-rewind 集群备机进程故障、设备断电、设备重启、网络故障 切换： 当集群备机发生进程故障、设备断电、设备重启、网络故障，主机的 repmgrd 监控进程发现备机连接不上，判断 备机状态为 down，如果集群是同步集群，则会修改 kingbase.auto.conf 文件将集群修改为异步集群。 同步改异步过程如下: 在备节点出现断网或停服务后，主节点通过 walsender 进程的状态判断同步备节点是否还 正常，在判断备节点出现问题后，主节点会通过修改 synchronous_standby_names 并 reload，来完成从同步模式转 换为异步模式的过程。 恢复： 自动：repmgr.conf 中 recovery 参数值设置为 automatic 或 standby 手动：repmgr.conf 中 recovery 参数值设置为 manual 手动恢复命令： $bin/repmgr -h host -U username -d dbname -p port node rejoin --force-rewind 集群全部节点进程故障、设备断电、设备重启 恢复： 自动：repmgr.conf 中 auto_cluster_recovery_level 参数值设置为 1, 在数据库节点间网络正常且集群中仅存在一 个主节点时，集群会尝试自动恢复。 手动：repmgr.conf 中 auto_cluster_recovery_level 参数值设置为 0, 集群不会自动做全故障恢复，需要人工启动 集群。 手动恢复命令： 35 第3章 KINGBASEES 读写分离集群 $bin/sys_monitor.sh start 3.5.3 存储故障 集群管理软件会监测数据库存储情况，遇到存储故障的情形（如果 use_check_disk=on）会关闭数据库，相关行 为如下表。 表 3.5.1: 存储故障 事件 集群应对行为 恢复 主库存储故障 repmgr 对主库实施停库，备库进而 1. 人工检查并恢复存储状态 自动切换 2.recovery 设为 automatic 时，被 停掉的主库会被自动恢复；recovery 设为 standby 时，需要手动恢复原 主库； 3. 手动恢复：执行命令 $bin/ rep- mgr -h 新主机 ip -U 数据库用户 -d 数据库名 -p 数据库端口 node rejoin --force-rewind 备库存储故障 repmgr 对备库实施停库；若流复制 1. 人工检查并恢复存储状态 配置为 sync，或者 quorum 模式下 2.recovery 备节点都故障，主库会转换流复制 standby 时，被停掉的备库会被主 为异步模式 (async 或 all 则不用处 库自动拉起；recovery 设为 manual 理) 时，需要手动恢复备库； 3. 设为 automatic 或 手动恢复：执行命令 $bin/ rep- mgr -h 新主机 ip -U 数据库用户 -d 数据库名 -p 数据库端口 node rejoin --force-rewind 3.5.4 数据损坏/人为错误 需要从备份做时间点恢复，见备份恢复一节描述。 3.5.5 响应慢或挂起 排查手段： 通过监控工具发现性能问题，需要人工及时排查。 36 第3章 KINGBASEES 读写分离集群 集群 repmgr 应对行为： repmgr 有一系列超时参数可用于限定对主库响应、延时、网络抖动等问题的探测灵敏度。超过设定灵敏度将触 发切换，参数说明见 2.2.3.3 节表格。 3.5.6 脑裂后处理 上述计划外停机故障均有概率产生一种现象--集群脑裂：即存在两个或以上的主机存活，并对外提供服务。如果 一旦出现此种现象，则需要人工参与，将集群恢复至正常状态。恢复步骤如下： 第一步：备份所有显示为主节点的 data 目录。可使用 cp 或手动执行一次备份工具的全量备份命令，可参考 《KingbaseES 备份与恢复工具手册》。 第二步：找出数据最新的主机，LSN 值大的数据库通常数据也较新，但是切换时间线时执行 checkpoint 会导致 较高时间线的数据库 LSN 大，但是数据并不一定最新，最保险的方式是连接到数据库中人为判断哪个主机的实际业 务数据最新。 查询 LSN 的 sql 命令： select sys_current_wal_lsn(); 第三步：判断主机的时间线，有 3 种方式： 第一种查看 data/sys_wal 目录下的.history 文件，文件名称中数字最大的.history 文件的数字就是该数据库的时 间线。 第二种通过控制文件查看该数据库的时间线，执行以下命令： $bin/sys_controldata -D $data_path 查看上述命令的结果中 Latest checkpoint’s TimeLineID 的值，该值即为数据库的时间线。 第三种通过 sql 查询当前时间线： select timeline_id from sys_control_checkpoint(); 第四步：根据第二步和第三步得出的结果，数据最新的主机时间线也是较高的情况下，只需在其他节点停止数据 库然后执行重新加入集群的命令： $bin/sys_ctl -D $data_path stop $bin/repmgr -h host -U username -d dbname -p port node rejoin --force-rewind 如果数据最新的主机时间线不是较高的情况下，需要额外增加参数--no-check-wal。 $bin/repmgr -h host -U username -d dbname -p port node rejoin --force-rewind --no-check-wal 37 第3章 KINGBASEES 读写分离集群 第五步：在各节点执行 cluster show 命令，确认集群状态 (只有 1 个主机，所有节点都是 running 状态)： $bin/repmgr cluster show 第六步：如果上述操作的结果全部正常，删除第一步备份的 data 目录，如果上述操作结果不正常，排查问题后 使用备份的 data 再次进行处理。 3.6 计划内停机操作 3.6.1 补丁、升级 3.6.1.1 资源补丁、升级 repmgr 主备集群提供的资源支持使用在线替换的方式升级，支持范围见下表： 表 3.6.1: 支持范围 资源 支持在线替换 备注 kingbase 否 arping 是 ip addr 是 ping 是 sys_securecmdd 是 需先停止备机，进行执行程序替换，重启可执行程序再升级主机 repmgrd 是 需先停止备机，进行执行程序替换，重启可执行程序再升级主机 kbha 是 需先停止备机，进行执行程序替换，重启可执行程序再升级主机 repmgr 是 sys_monitor.sh 是 kingbase 升级方式 1. 升级后版本兼容原有数据 升级方式：备份原有执行程序，直接替换 kingbase 可执行程序和相关组件。 升级后版本和原有版本未发生通讯或复制协议修改时可使用滚动升级： 2. 确认主备数据一致后，执行暂停功能，使集群不再自动进行切换和恢复操作 38 第3章 KINGBASEES 读写分离集群 $bin/repmgr service pause 依次停止各个备机，完成升级并重启。完成全部备机升级后选择其中一个 switch over 升级主机，最后完成原主 机的升级。 升级后版本和原有版本通讯或复制协议不兼容： 依次停止各个备机完成升级，最后停止主机完成升级并重启集群。 3. 升级后版本不兼容原有数据 目前只支持通过导出导入的方式升级，过程中需要停止对外服务。 停止使用数据库的应用 停止整个集群，记录集群的拓扑状态。 $bin/sys_monitor.sh stop 在主机操作： 备份数据库和原可执行程序 启动数据库进行实例级逻辑备份，并记录数据库初始化时指定的参数，无法在初始化后修改的内容包括： wal_segment_size，database_mode，data_checksums。 $bin/sys_dumpall -h host -U username -p port -f xxx.sql 停止数据库 $bin/sys_ctl -D $data_path stop 清理 data，使用部署工具按原有集群拓扑和初始化参数重新部署集群。 导入之前导出的数据 $bin/ksql -h host -U username -W password -d dbname -f xxx.sql 3.6.1.2 repmgr 补丁、升级 repmgr 组件的升级可使用以下几种方式： 39 第3章 KINGBASEES 读写分离集群 表 3.6.2: repmgr 组件的升级方式 停机升级 在线升级 版本限制 无 无 升级中服务可用 升级期间，对应用无法提供 升级中每个节点会停服务一次，对应用始终提供服务 性 服务 升级限制 无 不支持升级过程中故障，一旦升级过程故障则可能导致集群损 坏不可用 补丁和升级建议的方式： 根据用户实际需求来采取对应的升级方式，停机升级是更安全可靠的升级方式，必须一直提供数据库服务的情况 下采取在线升级。 3.6.1.2.1 停机升级方式 1 备份集群，主备的 data 目录。 cp -r $data_path/data $data_path/data_bak 2 集群全部停止 $bin/sys_monitor.sh stop 3 在集群中每个节点执行: 需要升级的可执行程序替换 4 集群启动 $bin/sys_monitor.sh start 3.6.1.2.2 在线升级 1 升级可执行文件 repmgr 和库文件 repmgr.so 可直接在各机进行替换，替换 repmgr.so 后需要重启 repmgrd 进 程。 2 升级后台监控进程 repmgrd 需要首先停掉 repmgrd 然后实施替换，替换后 kbha 进程将自动重启 repmgrd。 $ps –ef|grep repmgrd|grep –v grep # 获取 repmgrd 的 pid $kill -9 $PID; $cp $ 升级包目录/repmgrd $bin/repmgrd 3 升级 kbha 需要首先停掉 kbha 然后实施替换，替换后可手动重启 kbha。 40 第3章 KINGBASEES 读写分离集群 $ps –ef|grep kbha|grep –v grep # 获取 kbha 的 pid $kill -9 $PID; $cp $ 升级包目录/kbha $bin/kbha $bin/kbha -A daemon -f $bin/../etc/repmgr.conf 3.6.1.3 系统或硬件补丁、升级 如果硬件变更影响到所有的主机，如网络交换机更换，选择停机升级。如果硬件变更只影响单台或集群中部分服 务器，可以选择在线升级。操作方法见 repmgr 补丁、升级一节。 3.6.2 配置变更 3.6.2.1 配置文件修改 1. KingbaseES 数据库的配置修改，是否需要重启数据库取决于参数说明，如果需要重启数据库才能生效的配置变 更需要重启整个集群，必须同时修改主备的配置，然后重启集群。 $bin/sys_monitor.sh restart 不需要重启就可以生效的配置修改 $bin/sys_ctl -D $data_path reload 2. repmgr 的配置文件 repmgr.conf 的配置变更，需要重启 repmgrd 进程，一般情况下 kill repmgrd 进程，然后让 其被 kbha 守护进程重新启动。 kill -9 $repmgrd.pid 3.6.3 增加删除节点 图形界面方式：增加删除节点只需打开部署工具，选择之前部署的集群，然后右键根据菜单树选择进行删除节点 或新增节点。注意：只有部署此集群的部署工具可以对此集群进行增加，删除节点操作。 命令行方式：增加节点需要在待增加节点上执行 repmgr standby register 删除节点可以通过先 unregister 备机节点、再停止备机 standby 数据库方式，将 standby 节点从数据库集群删 除。最后，要在主节点上查询复制槽，将可能残留的原备机数据库的复制槽删除。 注意: 当集群节点数大于一时，不可以删除集群主节点。如果要删除主节点，必须先 switchover，将主节点转为 备节点，然后再将节点删除。 41 第4章 4 第 章 KINGBASEES CLUSTERWARE KingbaseES Clusterware 本部分包含以下内容： • KingbaseES Clusterware 简介 • 配置 • 故障处理行为 • 监控指标 • 从计划外停机中恢复 • 计划内停机操作 • 配置变更 4.1 KingbaseES Clusterware 简介 KingbaseES Clusterware 用于协调多种资源组成统一的服务，配合 KingbaseES 可以实现以下几种方案： 1. 使用共享存储的高可用方案 42 第4章 KINGBASEES CLUSTERWARE 图 4.1.1: 基于共享存储的高可用方案 2. 使用共享存储的高可用多活方案，适用于： a. 单个应用做了库级的解耦，可以通过分库将压力分散到不同数据库实例。以下是逻辑图示，正常运 行情况和单个节点故障的情况： 图 4.1.2: 单个应用做库级的解耦 b. 多个应用的集约化部署，每个应用使用单个数据库实例。以下是逻辑图示，正常运行情况和单个节 点故障的情况： 43 第4章 KINGBASEES CLUSTERWARE 图 4.1.3: 多个应用的集约化部署 这些高可用方案和读写分离集群方案的选择和比较请参考 高可用概述中“功能相近特性的选择”一节。 4.2 配置 数据库集群件 Clusterware 是一个复杂的系统，涉及多个数据库，多个主机，多种资源，多种配置，在用户现场 部署运行数据库集群件是一个较为复杂、困难的事情。特编写该文档，对实施在现场部署集群件起到一个规范和指 导的作用。本章节分为四部分，第一部分介绍集群部署相关配置，第二部分介绍故障处理行为，第三部分介绍监控指 标，第四部分介绍从计划外停机中恢复，第五部分介绍计划内停机操作，第六部分介绍配置变更。 44 第4章 4.2.1 硬件配置 4.2.1.1 限制 KINGBASEES CLUSTERWARE 表 4.2.1: 限制 服务器 非专用机，支持 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. 环境中有时间服务器的情况下各节点同步时间服务器 a. 如果时间服务器端有客户端 IP 限制，加入各节点 IP b. 各节点在 ntp.conf 中加入时间服务器配置（以 192.168.4.134 为例） server 192.168.4.134 prefer fudge 192.168.4.134 stratum 10 2. 环境中没有时间服务器的情况下设置集群中一个节点为 NTP 服务器，其他节点向此服务器同步时间。使用此种 方式时要注意在 NTP 服务器节点故障修复后重新加入网络时需要手动检查系统时间，可以设置为比运行节点中 时间最快的更快几秒。 a. 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 45 第4章 KINGBASEES CLUSTERWARE b. 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 自定义名称 2. 查看初始化信息 mkqdisk -f 自定义名称 -d -m 46 第4章 4.2.3.2 KINGBASEES CLUSTERWARE 成员管理（corosync）配置 4.2.3.2.1 说明 以下配置无特别说明： 1. 不包括不使用的段 2. 不包括默认的配置值 4.2.3.2.2 totem 段 表 4.2.2: totem 段 配置项 推荐配置和说明 version 固定值 2 cluster_name 集群内统一命名即可 Token 单位毫秒，节点的网络心跳超时时间，超时未收到节点的心跳会认为节点故障。 join 单位毫秒，集群成员协议中做一致性同步时的超时时间，超时将会延迟成员稳定的时间。 crypto_hash 加密相关配置，默认关闭但不配置会去系统的配置中获取导致报错。 crypto_cipher 加密相关配置，默认关闭但不配置会去系统的配置中获取导致报错。 4.2.3.2.3 totem.interface 段 表 4.2.3: totem.interface 段 配置项 推荐配置和说明 knet_ping_interval 单位毫秒，knet 的心跳间隔。 knet_ping_timeout 单位毫秒，在 timeout 时间内没有收到 ping 会认为 knet 连接断开，和 token 相似。 mcastaddr 默认设置即可，如果网络有控制，请找网管分配一个组播地址。 mcastport 默认，占用 5405 和 5404 端口。 47 第4章 KINGBASEES CLUSTERWARE 4.2.3.2.4 nodelist 段 表 4.2.4: nodelist 段 配置项 推荐配置和说明 ring0_addr 按推荐不使用 redundant ring 协议，只有 ring0_addr。 name 节点名，使用 hostname。 nodeid 各节点从 1 开始顺序增加。 4.2.3.2.5 quorum & quorum.device 段 表 4.2.5: 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 48 第4章 KINGBASEES CLUSTERWARE 4.2.3.2.6 quorum.device.disk 段 表 4.2.6: 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.7: logging 段 配置项 推荐配置和说明 to_logfile 除 syslog 外是否输出 log 到文件 logfile 文件路径，支持 logrotate 配置。 debug off 默认值为 off，为了方便现场 debug 时直接修改配置所以特别保留。 4.2.3.2.8 system 段 表 4.2.8: system 段 配置项 推荐配置和说明 state_dir 默认/var/lib/corosync，有文件位置需要可以变更。 49 第4章 KINGBASEES CLUSTERWARE 4.2.3.2.9 配置间关系 1. 两节点集群中不考虑 qdisk 的多次故障造成的投票时间增加，单次投票在 master io 故障情况下到新 master 选 举投票的时间最大为： interval * (tko + master_wait + upgrade_wait) + fence_timeout 2. fence_timeout 应小于 tko * interval 避免因 fence 导致心跳更新不及时。 3. 考虑 bid 过程中有新节点的恢复，master_wait 要比 tko_up 大。 4. qdevice 的 timeout 应该大于 qdisk 单次投票的最大时长避免正常投票过程超时。 5. qdevice 的 sync_timeout 应该大于 timeout。 6. 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 形式。 50 第4章 KINGBASEES CLUSTERWARE 4.2.3.3.2 Cluster options 表 4.2.9: 集群级别的配置参数 参数名称 默认值 建议 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 三种操作，每个操作有如下属性可以配置。 51 第4章 KINGBASEES CLUSTERWARE 表 4.2.10: 资源 operation 配置 属性名称 默认值 意义 id 唯一性的名称 name 操作的名称，如：monitor，start， stop。 interval 0 操作的频率，0 表示在需要的时候调 用，start 和 stop 操作一般设置为 0，monitor 需要调整该参数。 超时设置，超过该时间，操作没有 timeout 反应，默认为失败。 on-fail restart(如果设置了 fence，那么 stop 可以配置的值有： 默认的是 fence，如果没有 fence， • ignore 假装没有失败 那么 stop 默认的是 block) • 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 属性, 设置资源的全局属性, 无关资源以何种属性运行 52 第4章 KINGBASEES CLUSTERWARE 表 4.2.11: 资源 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 表示禁用该功 能。 见续表 53 第4章 KINGBASEES CLUSTERWARE 表 4.2.11 – 续表 属性名称 默认值 意义 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 54 第4章 KINGBASEES CLUSTERWARE 表 4.2.12: VMWare ESXi 环境资源配置 参数名称 默认值 说明 stonith: fence_vmware_soap ”” 配置 fence agent 类型 ipaddr ”” VMWare ESXi IP 地址 login、passwd ””、”” 登录用户名、密码 pcmk_host_check 如果配置了 pcmk_host_list 或者 若配置 none，表示 fenceagent 可以 pcmk_host_map，那么此参数的默 fence 全部节点。 认值是 static_list。如果以上两项都 没配置，1）fence 设备支持 list 操 作，那么默认值为 dynamic_list； 2）fence 设置支持 status 操作，不 支持 list 操作，那么默认值为 status。以上条件均不满足，默认值为 none。 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.13: IPMI 环境资源配置 参数名称 默认值 说明 stonith:fence_ipmilan ”” 表示 fence agent 类型 ipaddr ”” 此 IPMI 设备 IP 地址 login、passwd ””、”” 登录用户名、密码 见续表 55 第4章 KINGBASEES CLUSTERWARE 表 4.2.13 – 续表 参数名称 默认值 说明 pcmk_host_list ”” 此 IPMI 设备控制的节点 uname 列表由于 IPMI 设备一般为各节点 独占，因此这里一般仅为一个 uname。多节点集群，一般需要配置多 个 fence_ipmilan 资源，分别支持各 节点的 fence。 lanplus 此 agent 需要的参数，使用 IPMI 0 LAN(RMCP+) 协议，如服务器支 持 IPMI LAN(RMCP) 协议，也可 不配置此参数。 ipmitool_path IPMI 客户端二进制 ipmitool 路 ”/usr/bin/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.14: FileSystem 脚本参数 参数名称 默认值 说明 device ”” 块设备路径，mount 的-U -L 指定的设备，或者是 nfsmount 的源路劲。 directory ”” 挂载点，文件系统挂载点路径。 fstype ”” 文件系统类型 options ”” 指定 mount 的-o 属性 statusfile_prefix .Filesystem_status/ 监控状态文件存放位置，一般按默认处理。 见续表 56 第4章 KINGBASEES CLUSTERWARE 表 4.2.14 – 续表 参数名称 默认值 说明 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" 2. 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 57 第4章 KINGBASEES CLUSTERWARE Storage lock Storage lock 是一种 ocf 资源，其 agent 脚本为 sg_persist，位于 $OCF_ROOT/resource.d/heartbeat/sg_persist 目录下，该资源是为保护共享磁盘只被一个 node 访问。 该脚本提供的参数如下： 表 4.2.15: 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 提供的参数如下： 58 第4章 KINGBASEES CLUSTERWARE 表 4.2.16: 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 见续表 59 第4章 KINGBASEES CLUSTERWARE 表 4.2.16 – 续表 参数名称 默认值 意义 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.17: kingbase 参数 参数名称 默认值 意义 sys_ctl / opt/ Kingbase/ ES/ V9/ Server/ bin/ 指定 sys_ctl 命令位置，用于控制数据 sys_ctl 库启停。 /opt/Kingbase/ES/V9/Server/bin/ksql Ksql 的位置，用来判断 KingbaseES 服 ksql 务是否安装。 / opt/ Kingbase/ ES/ V9/ Server/ bin/ 指定 sys_isrady 位置，e 用于 moni- sys_isready tor。 kb_data /opt/Kingbase/ES/V9/data 指定 KingbaseES 的 data 目录位置 kb_dba kingbase 指定 KingbaesES 的 OS 属主 kb_user system 指定监控连接的数据库用户名 kb_host ”localhost” 指定 KingbaseES 监听的 IP 地址,0.0.0.0 sys_isready 表示监听本机上所有 IP 地址。 kb_port 54321 指定 KingbaseES 监听的端口 见续表 60 第4章 KINGBASEES CLUSTERWARE 表 4.2.17 – 续表 参数名称 默认值 意义 kb_libs /opt/Kingbase/ES/V9/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/V9/Server/bin/sys_ctl" \ ksql="/home/kingbase/V9/Server/bin/ksql" \ sys_isready="/home/kingbase/V9/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/V9/Server/lib" \ kb_db="template1" \ 61 第4章 KINGBASEES CLUSTERWARE logfile="/home/kingbase/V9/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.18: PING 参数 参数名称 默认值 意义 pidfile ”${HA_VARRUN%%/}/ping-$ PID file {OCF_RESOURCE_INSTANCE}” 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 的详细日志 配置实例如下： 62 第4章 KINGBASEES CLUSTERWARE 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.19: Location 约束属性 属性名称 默认值 意义 id 全局唯一名称 rsc 约束的资源名称，和 rsc-pattern 必须提供一个。 rsc-pattern POSIX 类的正则表达式，模糊匹配约束资源的名称，和 rsc 必 须提供一个。 node 约束指定的节点名称 score 该约束的分数 见续表 63 第4章 KINGBASEES CLUSTERWARE 表 4.2.19 – 续表 属性名称 默认值 意义 resource-discovery always 是否检测该资源已经运行，有如下值： • always 总是检测资源在各个节点是否运行 • never 从不检测 • exclusive 总是检测资源在本节点是否运行，不管其他节点。 配置实例如下： 如下实例配置 FIP1 在 node1 上运行的分数为 1000 crm configure location FIP1-on-node1 FIP1 1000: node1 Order 约束能够配置资源启动的顺序，资源不一定在一个节点上启动，其主要有如下属性 表 4.2.20: 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 可以以不同的顺序 运行，但一定要一个完成后，另一个才能完 成。 见续表 64 第4章 KINGBASEES CLUSTERWARE 表 4.2.20 – 续表 属性名称 默认值 意义 symmetrical TRUE for mandatory and op- 如果为 true，那么相反操作适用相反的顺 tional kinds. FALSE for serialize 序，如 B start 在 A start 之后，那么 B stop kind 在 A stop 之前。 配置实例如下： CLONE-PINED 资源必须在 DB1_GROUP 资 源 启 动 之 前 启 动， 而 CLONE-PINGD 资源关闭需在 DB2_GROUP 停止后。 crm configure order cluster-order1 CLONE-PINGD DB1_GROUP Colocation 约束能够配置资源的结合性，其属性如下： 表 4.2.21: Colocation 约束属性 属性名称 默认值 意义 id 该约束的唯一名称 rsc 需要与 with-rsc 放在一块的资源名称 with-rsc 配置 colocatoin 约束的目标资源名称，一般来说，clusterware 会优先决定那个节点运行该资源，然后决定 rsc 资源放在哪运行。 node-attribute #uname score 运行 rsc 和 with-rsc 资源的该值必须一致 该约束的分数，+INFINITY 表示两个资源永远在一块 运行，-INFINITY 表示两个资源永远不再一块运行。 配置实例： crm configure colocation cluster-colo1 inf: DB1_GROUP CLONE-PINGD 4.2.3.3.7 资源迁移分数配置 Pacemaker 可以设置资源迁移的分数，通过合理设置资源保留当前节点运行的分数，能够达到高可用与负载均衡 的平衡点。 如果考虑高可用性，即重启节点，不对资源产生迁移，需确保 location 约束的分数 + 该分数都大于最大的 location 得到的分数，如果考虑性能，即资源负载问题，那么需要将该值设置的越小越好 配置实例，将资源迁移分数配置为 500。 65 第4章 KINGBASEES CLUSTERWARE crm configure rsc_defaults resource-stickiness=500 4.2.3.3.8 Group 资源与 CLONE 资源 1）. Group 资源 通常来说，集群可能存在一系列资源，这些资源需要运行在一起，启动顺序有严格要求，停止有相反的顺序， 当然可以通过 location，order，colocation 约束能达到该要求，但配置起来较麻烦，为了简化配置，pacemaker 提供 group 资源的概念。 表 4.2.22: 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.23: clone 资源的属性 属性名称 id 默认值 意义 唯一的名称 配置实例如下： 66 第4章 KINGBASEES CLUSTERWARE 将 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 67 第4章 KINGBASEES CLUSTERWARE 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 68 第4章 KINGBASEES CLUSTERWARE 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/V9/Server/log 目录。 crm configure primitive DB1 ocf:kingbase:kingbase \ params sys_ctl="/home/kingbase/V9/Server/bin/sys_ctl" \ ksql="/home/kingbase/V9/Server/bin/ksql" \ sys_isready="/home/kingbase/V9/Server/bin/sys_isready" \ 69 第4章 KINGBASEES CLUSTERWARE kb_data="/sharedata/data1/data" \ kb_dba="kingbase" kb_host="0.0.0.0" \ kb_port="36321" \ kb_user="system" \ kb_libs="/home/kingbase/V9/Server/lib" \ kb_db="template1" \ logfile="/home/kingbase/V9/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/V9/Server/bin/sys_ctl" \ ksql="/home/kingbase/V9/Server/bin/ksql" \ sys_isready="/home/kingbase/V9/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/V9/Server/lib" \ kb_db="template1" \ logfile="/home/kingbase/V9/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 正好相反。 70 第4章 KINGBASEES CLUSTERWARE 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 网络类故障 71 第4章 KINGBASEES CLUSTERWARE 表 4.3.1: 网络类故障 故障类 故障处理行为 业务影响 型 网络类 数据库端口占用 故障 故障节点节点会尝试重启数据库资源， 1. 数据库端口被占用后业务中断 达到 timeout（120s）后转移资源至另 2. 资源转移成功后业务恢复正常 外节点。 网络中断 对于节点整个网络中断（不包含 1. ipmi），节点会在检测网络中断 30s 后 1. 网络中断后业务中断 2. 资源转移成功后业务恢复正常 重启服务器，重启后该节点资源会转移 至可用节点； 2. 对于心跳线网络中断，此时主节点 会 fence 备机节点并转移资源至可用节 点。 网络丢 包 网络延 10% 服务正常，未触发资源故障。 业务正常，有一定延迟。 >10% 服务正常，未触发资源故障。 业务延迟较大，出现超时报错。 0.5s-5s 服务正常，未触发资源故障。 业务延迟较大，出现超时报错。 1:1 1. 选取 qdevice 的 master 所在集群为可 1. 节点被 fence 后数据库业务中断 用节点 (2 节点集群，id 小的节点会升 2. 数据库资源转移成功后恢复正常 迟 网络单 次分区 级为 master)。 2.Fence 其他节点 3. 转移资源至可用节点 1:2 1. 节点数量为 2 的集群获得 quorum 节 1. 被 fence 节点数据库业务中断 点数量为 1 的节点失去 quorum 2. 数据库资源转移成功后恢复正常 2.Fence 失去 quorum 节点 3. 转移资源至可用节点 1:1:1 1. 网络分区后，节点 id 小的节点获得 1. 被 fence 节点数据库业务中断 quorum 2. 数据库资源转移成功后恢复正常 2. 获得 quorum 的节点 fence 其它节点 3. 转移资源到获得 quorum 的节点 网关失联 节点会在检测网络中断 30s 后重启服务 1. 资源开始转移后数据库业务中断 器，重启后该节点资源会转移至可用节 2. 数据库资源转移成功后恢复正常 点。 72 第4章 4.3.2 KINGBASEES CLUSTERWARE 状态变化类故障 注意: 目前资源的 stop 操作 on-fail 设置是 fence，如果进程的 hang 导致资源的 stop 无法完成会导致节点被 fence， 即使已经没有其他可用节点。 表 4.3.2: 状态变化类故障 故障类 故障处理行为 业务影响 型 状态变 关机 1.Fence 故障节点（关机后的节点会 1. 数据库节点关机后业务中断 化类故 因 fence 操作重启） 2. 数据库资源转移成功后恢复正常 障 2. 转移故障节点资源到可用节点 掉电（IPMI 电源保持） 1.Fence 故障节点 1. 数据库节点关机后业务中断 2. 转移故障节点资源到可用节点 2. 数据库资源转移成功后恢复正常 3. 若节点长期掉电或因硬件损坏导 致无法启动，会因 fence 失败导致资 源无法正确转移。 重启 1.Fence 故障节点（reboot 的节点可 1. 数据库节点关机后业务中断 能会在 reboot 过程中再次被 fence 2. 数据库资源转移成功后恢复正常 触发 reboot） 2. 转移故障节点资源到可用节点 数据库意外关闭 pacemaker 在检测到数据库 down 掉 1. 数据库停止后业务中断 后自动重启数据库 2. 数据库重启成功后恢复正常 进程异 pacemaker 1. 可用节点会当选为 DC 节点 1. 数据库节点被 fence 后业务中断 常终止 （DC） 2.Fence 故障节点 2. 数据库资源转移成功后恢复正常 3. 转移故障节点资源到可用节点 pacemaker （非 1.Fence 故障节点 1. 数据库节点被 fence 后业务中断 DC） 2. 转移故障节点资源到可用节点 2. 数据库资源转移成功后恢复正常 pacemaker-co Pacemaker ntrold pacemaker-co ntrold 意外退出后重 主进程会在检测到 无影响 新生成 pacemaker-controld 进程 见续表 73 第4章 KINGBASEES CLUSTERWARE 表 4.3.2 – 续表 故障类 故障处理行为 业务影响 型 主进程会在检测到 pacemaker-b 1.Pacemaker ased pacemaker-b ased 意外退出后重新 无影响 生成 pacemaker-based 进程 2.DC 节点的 pacemaker-based 进程 故障可能导致该节点被 fence 主进程会在检测到 pacemaker-f Pacemaker enced pacemaker-f enced 意外退出后重新 无影响 生成 pacemaker-fenced 进程 主进程会在检测到 pacemaker-e Pacemaker xecd pacemaker-e xecd 意外退出后重新 无影响 生成 pacemaker-execd 进程 主进程会在检测到 pacemaker-a Pacemaker ttrd pacemaker-a ttrd 意外退出后重新生 无影响 成 pacemaker-attrd 进程 主进程会在检测到 pacemaker-s Pacemaker chedulerd pacemaker-s chedulerd 意外退出后 无影响 重新生成 pacemaker-schedulerd 进 程 corosync 1.Fence 故障节点 1. 故障节点数据库被 fence 后业务中 2. 转移故障节点资源到可用节点 断 2. 数据库资源转移成功后恢复正常 3. 恢复时长：fence 成功时间 + 资源 转移成功时间，总时间大于 20s。 - 1.slave 节点的 corosync-qdevice 检 1. 故障节点数据库被 fence 后业务中 qdevice (master) 测到主节点 corosync-qdevice 故障后 断 升级自己为主节点 2. 数据库资源转移成功后恢复正常 2.Fence 故障节点 3. 恢复时长：fence 成功时间 + 资源 3. 转移故障节点资源到可用节点 转移成功时间，总时间大于 3min。 corosync 状态变 corosync-qde 1.Fence 故障节点 1. 故障节点数据库被 fence 后业务中 化类故 vice(slave) 2. 转移故障节点资源到可用节点 断 障 2. 数据库资源转移成功后恢复正常 3. 恢复时长：fence 成功时间 + 资源 转移成功时间，总时间大于 3min。 见续表 74 第4章 KINGBASEES CLUSTERWARE 表 4.3.2 – 续表 故障类 故障处理行为 业务影响 型 kingbase pacemaker 在检测到数据库进程故 数据库进程故障后业务中断数据库 障后自动重启数据库 重启成功后恢复正常恢复时长：10s 内。 进程 pacemaker (DC) hang 1.hang 住节点的 crm_mon 无法查 1.Pacemaker 进程 hang 住后业务可 看集群状态 正常运行 2. 资源保持当前状态不变 2.hang 住的 pacemaker 恢复后资源 3. 此时集群发生故障无法进行故障 会重启 转移—集群失去高可用 4. 恢复 hang 住的 pacemaker 后该节 点资源会重启 pacemaker 1.hang 住节点的 crm_mon 无法查 1. 不影响，期间该节点会失去高可 (非 DC) 看集群状态 用。 2. 资源保持当前状态不变 3. 此时集群发生故障无法进行故障 转移—集群失去高可用 corosync 1.Fence 故障节点 1. 故障节点数据库被 fence 后业务中 2. 转移故障节点资源到可用节点 断 2. 数据库资源转移成功后恢复正常 - 1.slave 节点的 corosync-qdevice 检 1. 故障节点数据库被 fence 后业务中 qdevice (master) 测到主节点 corosync-qdevice 故障后 断 升级自己为主节点 2. 数据库资源转移成功后恢复正常 corosync 2.Fence 故障节点 3. 转移故障节点资源到可用节点 corosync qdevice (slave) - 1.Fence 故障节点 1. 故障节点数据库被 fence 后业务中 2. 转移故障节点资源到可用节点 断 2. 数据库资源转移成功后恢复正常 kingbase 1.pacemaker 在检测到数据库故障后 1. 数据库进程 hang 住后业务中断 尝试在故障节点停止数据库 2. 数据库资源转移成功后恢复正常 2. 停止超时后，将故障节点的 failcount-DBX 置为 INFINITY。 3.Fence 故障节点 4. 转移故障节点资源到可用节点 见续表 75 第4章 KINGBASEES CLUSTERWARE 表 4.3.2 – 续表 故障类 故障处理行为 业务影响 型 系统崩溃 系统时间跳变 1.Fence 故障节点 1. 数据库节点系统崩溃后业务中断 2. 转移故障节点资源到可用节点 2. 数据库资源转移成功后恢复正常 1. 集群状态正常，业务正常运行。 无影响 2. 一段时间后 ntpd 自动正确同步时 间。 4.3.3 资源耗尽类故障 表 4.3.3: 资源耗尽类故障 故障类型 故障处理行为 业务影响 资源耗尽类故 磁盘满（数据 资源状态未发 1. 数据库业务执行失败，日志报错 could not write to log file: No 障 盘） 生变化，各资 space left on device 。 源未发生故 2. 磁盘空间充足后，可自动恢复正常。 障。 磁盘 IO 高 1. 资源状态未 1. 无影响 (数据盘) 发生变化，各 2. 若文件系统资源故障重启，则在资源故障后到资源恢复前业 资源未发生故 务执行失败。 障。 2. 可能导致文 件系统资源故 障重启 投票盘 IO 高 1. 资源状态未 1. 无影响 发生变化，各 2. 若文件系统资源故障重启，则在资源故障后到资源恢复前业 资源未发生故 务执行失败。 障。 2. 可能导致文 件系统资源故 障重启 见续表 76 第4章 KINGBASEES CLUSTERWARE 表 4.3.3 – 续表 故障类型 内存使用率高 故障处理行为 业务影响 1. 资源状态未 1. 无影响 发生变化，各 2. 若资源故障重启，则在资源故障后到资源恢复前业务执行失 资源未发生故 败。 障。 2. 可能导致资 源故障重启 cpu 利用率高 1. 资源状态未 1. 无影响 发生变化，各 2. 若资源故障重启，则在资源故障后到资源恢复前业务执行失 资源未发生故 败。 障。 2. 可能导致资 源故障重启 4.4 监控指标 表 4.4.1: 监控指标 参数指标 取值范围 异 常 范 围/级 获取方式 别 Pacemaker 进 stopped /run- 程状态 ing Corosync 进 stopped/ run- 程状态 ing Corosync- Stopped/ run- qdevice 进程 ning stopped/错误 /etc/init.d/pacemaker status stopped/错误 /etc/init.d/corosync status stopped/错误 /etc/init.d/corosync-qdevice status offline, crm_mon -1 | grep -E ”offline | standby | Online” 状态 节点状态 资源状态 offline, on- line,standby standby/错误 Failed,started failed/错误 crm resouce show | grep failed ,starting 见续表 77 第4章 KINGBASEES CLUSTERWARE 表 4.4.1 – 续表 参数指标 取值范围 异 常 范 围/级 获取方式 别 查看集群是否 Yes/no no/错误 corosync-quorumtool -s| grep Quorate: 0 ——nnodes 0/错误 ./ corosync-qdevice-tool -sv -p / opt/ KingbaseHA / corosync- 有 quorum 模式 disk master_id qdevice/var/run /corosync-qdevice /corosync-qdevice.sock | grep ”master id” | awk -F’:’ ’{print $2}’ 存储 STATE MOUNTED / >0/错误 crm storage | grep UNMOUNT | wc -l >0/告警 crm storage | grep -v -e ”VOTEDISK\|PATH” | awk ’{print (($4 UN- MOUNTED 存储容量 0/1 / ($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. 移动资源到重加入的节点 a. 通过 crm_mon 确认资源当前运行的节点（假设节点名为节点 2） b. 移动资源（假设名称为资源 1）从节点 2 到重加入的节点 1 c. 通过 crm_mon 确认资源正确转移 d. 清理节点 2 上的资源移动规则 78 第4章 KINGBASEES CLUSTERWARE 存储故障/数据损坏的恢复 4.5.2 clusterware 本身不提供存储支持或数据冗余，故障后 clusterware 需要从备份恢复配置。 集群故障或站点故障的恢复 4.5.3 clusterware 本身不提供跨站点或集群的冗余，故障后 clusterware 需要从备份恢复配置。 4.5.4 FENCE 设备故障的恢复 FENCE 设备是保障集群共享资源被正确操作的基础，集群中节点的 FENCE 设备损坏时该节点再发生其他故障 将导致集群试图 FENCE 该节点而停止其他服务。 恢复方式： 1. 手动处理故障 a. 手动通过电源开关关闭 FENCE 设备损坏的节点 b. 在正常节点上执行 stonith_admin -C 故障节点 2. 修复故障的 IPMI 设备 3. 按照主机故障的恢复方式恢复节点 4.5.5 clusterware 备份和恢复方式 1. 备份 a. 成员管理：复制 corosync.conf 配置文件 b. 资源管理：crm configure save 备份文件 2. 恢复 a. 恢复软件环境：重新配置系统参数，安装 clusterware b. 恢复配置： i. 成员管理：复制 corosync.conf 到配置文件位置 ii. 资源管理：crm configure load replace 备份文件 4.6 计划内停机操作 补丁、升级 79 第4章 4.6.1 KINGBASEES CLUSTERWARE 资源补丁、升级 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. 脱管全部资源 80 第4章 KINGBASEES CLUSTERWARE crm_attribute --name maintenance-mode --update true 2. 在集群中每个节点执行 a. 停止 clusterware b. 完成变更 3. 在集群中每个节点执行： a. 启动 clusterware b. 验证配置确认没有错误和警告 4. 通过 crm_mon 确认全部资源状态被正确识别 5. 重新管控资源 4.6.2.2 滚动方式 在集群中一个节点（假设节点名为节点 1）执行： 1. 设置节点为 standby 状态 crm_standby --node 节点 1 -v on 2. 通过 crm_mon 确认资源都正确转移到其他节点 3. 停止 clusterware /etc/init.d/pacemaker stop /etc/init.d/corosync-qdevice stop /etc/init.d/corosync stop 4. 完成变更 5. 启动 clusterware /etc/init.d/corosync start /etc/init.d/corosync-qdevice start /etc/init.d/pacemaker start 6. 验证配置确认没有错误和警告 crm_verify --live-check 7. 清除节点 standby 状态 crm_standby --node 节点 1 -v off 81 第4章 KINGBASEES CLUSTERWARE 如果需要，移动资源到变更后的节点 1. 通过 crm_mon 确认资源当前运行的节点（假设节点名为节点 2） 2. 移动资源（假设名称为资源 1）从节点 2 到变更后的节点 1 crm_resource -M 节点 1 -r 资源 1 3. 通过 crm_mon 确认资源正确转移 4. 清理节点 2 上的资源移动规则 crm_resource -U --node 节点 2 -r 资源 1 5. 在剩余节点上重复执行 1、2 中的步骤 4.6.3 系统或硬件补丁、升级 如果变更需要重启主机或是停止网络等影响资源运行的操作，选择滚动方式，否则选择脱管资源方式。操作方法 见 clusterware 补丁、升级一节。 4.7 配置变更 4.7.1 资源配置 1. 对资源参数的修改不会造成服务中断。 2. 修改会影响资源运行位置的参数会造成资源迁移，导致服务短时间中断，需要申请停机时间。 4.7.2 成员配置 1. 不包括变更成员数量的配置变更。 2. 修改需要重启 clusterware，建议使用脱管资源方式变更配置。 4.7.3 增加删除节点 增加删除节点需要同时修改成员配置和资源配置，对配置的更改请咨询产品服务人员。 82 第 5 章 KINGBASEES 备份恢复 5 第 章 KingbaseES 备份恢复 本部分包含以下内容： • KingbaseES 备份恢复简介 • 重要提示信息 • 备份方案和适用场景 • 制定备份策略 • 独立备份 • 非独立备份 5.1 KingbaseES 备份恢复简介 数据库集群的物理备份恢复，是保证数据安全的最后一道屏障，因此其重要性在日常维护中涉及较少，但如果系 统因为各种原因出现不可逆转的数据问题时，从备份恢复将维护数据库系统的高可用性。但备份功能才是一切的基 础，是需要日常维护和关注的。该文档将对现场实施部署集群的备份和恢复起到一个规范和指导的作用。本手册分为 四部分，第一部分介绍集群备份还原的相关配置，第二部分介绍备份还原功能的监控指标，第三部分介绍集群从计划 外停机中恢复，第四部分介绍计划内停机操作。 集群的备份恢复功能从逻辑上看，针对的是整个集群，而不是某个节点。 本备份还原功能包含四个文件： • sys_backup.sh 初始化配置脚本 • sys_backup.conf 初始化配置文件 • sys_rman 备份还原二进制可执行文件 • sys_rman.conf 备份还原配置文件 83 第 5 章 KINGBASEES 备份恢复 5.2 重要提示信息 • 启动数据库时，应该使用绝对路径来指定 data 目录所在。 • sys_rman 二进制文件，在集群和备份节点上绝对路径应该一致。 • 集群数据节点和备份节点，root 用户和数据库用户应该是 ssh 免密登录的，且交叉免密登录。 • 如果操作系统是 UOS 或者 Deepin，需要在/etc/profile 末尾增加一行。 export OPENSSL_CONF=/etc/ssl/ • 默认情况下，工具开启了压缩模式，压缩将节约空间、消耗时间；不压缩将节约时间、消耗空间。可以在 sys_rman.conf 中调整。 • 如果集群包含 witness 节点，该 witness 节点的 IP，不能作为 _one_db_ip。 • 集群中的每个数据库节点、备份服务器，都将创建 REPO_PATH，如果已有此目录或权限问题，将报错退出。 5.3 备份方案和适用场景 5.3.1 备份方案 备份的典型部署方式分为两类： • 独立备份 – 在数据库节点以外，搭建一台专用于备份的服务器节点。 – 要求备份服务器与所有数据库节点网络通畅。 – 备份目标可以是单节点或多节点集群，支持对多个目标备份。 • 非独立备份 – 非独立备份指的是在现有数据库节点上进行备份还原的操作。 – 要求具有良好的独立存储通道和充足的存储空间。 – 多节点情况下需要每个节点都启用本地备份。 5.3.2 适用场景 84 第 5 章 KINGBASEES 备份恢复 表 5.3.1: 两种方案比较 独立备份 非独立备份 硬件节点利用率 N 硬件节点，N-1 数据节点。 N 硬件节点，N 数据节点 整体容灾可靠性 高 稍逊 备份容量（目标单机） 备份保留份数可适当增加 备份与实际数据共同占用主机容 量，需要恰当的备份周期和保留份 数。 备份容量（目标多机） 备份集中管理 备份冗余度更高 网络要求 备份、恢复时通过网络传输数据， 对网络无要求 对网络连通性和带宽有要求。 备份耗时 恢复耗时 单点故障影响 5.3.2.1 在非独立备份的耗时基础上额外需 从数据库存储读取数据写入备份存 要从目标机将数据传输到备份机 储 在非独立备份的耗时基础上额外需 从备份存储读取数据写入数据库存 要从备份机将数据传输到目标机 储 较少 较多 非独立备份单节点 此场景适用于单独主机的场景。 85 第 5 章 KINGBASEES 备份恢复 图 5.3.1: 非独立备份单节点 5.3.2.2 非独立备份多节点 此场景为主备双机常规环境设计，其中 REPO 节点位于数据库集群的主节点。 86 第 5 章 KINGBASEES 备份恢复 图 5.3.2: 非独立备份多节点 5.3.2.3 独立备份单节点 此场景适用于单独主机的场景。 87 第 5 章 KINGBASEES 备份恢复 5.3.2.4 独立备份多节点 此场景为主备双机常规环境设计，主要的备份信息来源于备机，极大地减少备份为主机带来的性能损耗，且增加 了第三方专用存储服务器，用于存放和管理备份文件。 88 第 5 章 KINGBASEES 备份恢复 图 5.3.3: 独立备份单节点 5.4 制定备份策略 5.4.1 备份恢复过程 备份过程： • 根据备份时的选项，确定本次备份的依赖关系。 • 如果本次是全量备份，则忽略此步骤。 • 如果是增量备份，选择上一次备份（任意类型）作为依赖。 • 如果是差异备份，选择上一次全量备份作为依赖。 • 根据数据库配置，获取全部数据、配置、核心文件列表。 • 根据文件 CheckSum 和时间来确定本次备份需要拷贝或者信任依赖备份（不拷贝文件)。 • 开始拷贝过程，逐个文件开始拷贝，可多进程开展。 • 拷贝完成后，根据配置保留数目和现有数目，选择性移除过期备份文件集。 恢复过程： • 根据恢复时的选项，程序自动选择一个全量备份。 89 第 5 章 KINGBASEES 备份恢复 • 或者选择最新（默认）、指定时间、指定备份集、指定 XID 等。 • 并自动匹配恰当的增量和差异备份集。 • 复制到目标路径，如果有压缩，解压缩。 • 在复制完成后，启动本节点为新的主节点（默认）。 • 选项可指定，复制完成后，进入 PAUSE 模式。 • 选项可指定，复制完成后，等待管理员手动启动数据库。 5.4.2 备份策略制定 需要考虑的备份策略选择项： 表 5.4.1: 备份策略选择项 备份方案 独立/非独立备份 备份类型和频率 全量/增量/差异备份各类型备份频率 备份容量 保留的备份个数，是否压缩。 1. 独立/非独立备份 参见备份方案和适用场景 选择。 2. 备份类型和频率 参考备份恢复过程 描述： a. 全量备份使用最多资源，包括备份中对目标数据库资源的抢占和备份后对容量的占用，备份时间最长但恢 复时间最短。 b. 增量有效减少对资源的使用但相比从全量恢复，增加了恢复时间。 c. 差异备份在备份速度、资源占用和恢复速度上介于全量和增量之间。 需要根据硬件的 I/O 带宽、容量和恢复的 RTO 需求选择备份类型和频率，保证最差情况下（故障时间点发生 在下次全量备份完成前），恢复时从基础备份到最近的增量/差异备份再加上备份到故障时点的数据增量，以上 整体的恢复时间能满足 RTO 需求。 3. 备份容量 增加保留的备份数 优势：可以应对备份损坏或是应对发生很久后才发现的需要时间点恢复的情况。 劣势：更多的容量占用。 启用压缩： 优势：减少备份容量。 90 第 5 章 KINGBASEES 备份恢复 劣势：增加备份和恢复时间。 根据硬件情况考虑以上选择。 5.4.3 常用策略 在制定方案时可能还不能很好的了解系统的情况，此时可以使用以下常用策略： 全量备份周期：7 天； 增量备份周期：1 天； 保留份数：5 份全量备份，不压缩存储； 5.5 独立备份 5.5.1 配置 5.5.1.1 硬件-限制 具备独立与备份目标数据库服务器的备份服务器。 备份服务器与所有数据库节点间网络通畅。 备份将额外占用存储空间。 推荐配置下大致预估的额外空间：3 倍于实际数据库存储占用空间。 91 第 5 章 KINGBASEES 备份恢复 5.5.1.2 硬件-推荐配置 图 5.5.1: 推荐配置 5.5.1.3 数据库配置 确保备份目标中的全部数据库节点 archive_mode 配置为 on. grep archive_mode $db_path/esrep.conf archive_mode = on 注意: archive_command 将由配置脚本自动填充实际内容。 5.5.1.4 备份还原功能配置 注意: init start 命令要求在 REPO 备份服务器节点上执行。 需要注意 _single_data_dir 应复制数据库的 data_directory 的内容，在不同启动方式下 data_directory 可能包 含相对路径。 92 第 5 章 KINGBASEES 备份恢复 • 初始化配置时 1 准备初始配置文件 sys_backup.conf 此配置文件模板位于 share 目录下，填充配置完成后可以移动到 $bin_path 目录下。 # 配置文件关键片段 # 指明当前的数据库是单机或者集群，single/cluster _target_db_style=”single” # 建议配置数据库的 primary node 的 IP，只需一个 IP 地址 _one_db_ip=”192.168.1.11” # 备份服务器所在的 IP # 单机 + 内在备份服务器 设置为等同于$_one_db_ip # 单机 + 外部备份服务器 设置外部备份服务器 _repo_ip=”192.168.1.66” _stanza_name=”kingbase” _os_user_name=”kingbase” # 备份文件实际存储路径，注意磁盘容量 _repo_path=”/home/kingbase/back_dir” # 全量备份保留份数 _repo_retention_full_count=5 # 全量备份周期（天数） _crond_full_days=7 # 差异备份周期（天数） _crond_diff_days=0 # 增量备份周期（天数） _crond_incr_days=1 # 自动执行全量备份的时间点，2 表示凌晨 2 点 _crond_full_hour=2 # 自动执行差异备份的时间点，3 表示凌晨 3 点 _crond_diff_hour=3 # 自动执行增量备份的时间点，4 表示凌晨 4 点 _crond_incr_hour=4 # 带宽限制, 单位为 Mb/s, 默认值 0 时无限制 _band_width=0 # 定义指令 _os_ip_cmd="/sbin/ip" _os_rm_cmd="/bin/rm" _os_sed_cmd="/bin/sed" _os_grep_cmd="/bin/grep" # 单机设置 _single_data_dir=”/home/kingbase/ES/V9/data” _single_bin_dir=”/home/kingbase/ES/V9/Server/bin” _single_db_user=”system” _single_db_port=”54321” # 开启时使用 sys_securecmd, 未开启使用普通 ssh _use_scmd=on 93 第 5 章 KINGBASEES 备份恢复 2 执行初始化配置 初始化备份还原功能 $bin/sys_backup.sh init 启动备份还原功能 $bin/sys_backup.sh start 3 确认备份还原功能配置文件 sys_rman.conf cat $repo_path/sys_rman.conf • 日常备份时 常规日常备份由系统的 CRONDTAB 触发，不需要额外关注。 如果因为业务需要，可使用如下命令执行一次全量备份。 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=full backup 或者差异备份 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=diff backup 或者增量备份 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name 注意: --type=incr backup 要求管理员在 sys_backup.sh init 前，数据库节点与外部备份节点之间以相应的 OS 用户，互相进行 SSH 登 录，以验证 SSH 登录场景，通过 StrictHostKeyChecking 的检测。 如果使用 securecmdd 功能，需要在每个 DB 节点和 REPO 节点启动 sys_securecmdd 相关服务。 • 故障还原时 在数据节点上执行还原动作。 注意: 如果实际备份文集的 $repo_path 遭到了损坏，还原功能将失效。 备份和还原时，工具将自动进行文件级别的有效性校验。 1 根据不同的故障及场景开展还原 如果是独立外部备份的情况下，数据节点的 $repo_path 已经损坏的情况下， 从外部备份节点拷贝 $repo_path/sys_rman.conf 到数据节点相应目录， 94 第 5 章 KINGBASEES 备份恢复 并作出少许修改，详细请参考 附录 bsysrmanconf 配置说明。 如果 $data_path 没有任何文件 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name restore 如果 $data_path 有可信赖可保留的文件 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --delta restore 2 启动刚刚还原的数据节点 5.5.2 监控指标 确认 CRONDTAB 报告备份还原功能 sys_rman cat /etc/cron.d/KINGBASECRON 在 REPO 节点，磁盘剩余多少空间。 df -h 在 REPO 节点，确认备份已经消耗了多少磁盘空间。 du -h $repo_path 查看已产生备份文件集列表 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name info 5.5.3 从计划外停机中恢复 因为备份还原功能并不是 24 小时工作，从计划外停机中恢复时，不需要额外的行为。 如果备份文件集发生了损坏，需要尽快进行全量备份来保证至少有一个可用的全量备份。 确认 CRONDTAB 报告备份还原功能 sys_rman cat /etc/cron.d/KINGBASECRON 5.5.3.1 集群还原策略 如果集群中一个节点出现严重问题时，应该采用 repmgr 工具的 clone 功能。 95 第 5 章 KINGBASEES 备份恢复 新节点上线后，使用 repmgr 工具接入集群中。 如果集群所有节点都出现严重问题时，应该采用本工具进行还原。 1 选择一个数据库节点，使用还原功能； 2 使用 repmgr 工具 clone 其他节点； 3 整个集群恢复正常工作状态。 5.5.3.2 站点故障 站点故障包括网络原因、电力中断或人为原因导致站点设备停止工作，若没有跨站点的备节点，需要人工恢复集 群 如果故障没有造成存储文件的损坏，按照集群章节的方法恢复集群。 如果故障造成存储文件的损坏，按照本章节的方法还原数据系统。 5.5.3.3 实例或计算机故障 集群主节点发生进程故障、设备断电、设备重启、网络故障 根据集群章节的方法处理，处理过程应该避开每日备份节点； 或者 sys_backup.sh stop 暂停自动备份服务后，处理异常，然后 sys_backup.sh start 启动自动备份服务。 集群备机进程故障、设备断电、设备重启、网络故障 备库故障不影响备份工作的开展。 5.5.3.4 存储故障 集群管理软件会监测数据库存储情况，遇到存储故障的情形会关闭数据库，相关行为如下表 表 5.5.1: 存储故障 事件 集群应对行为 备份功能相关 主库存储故障 repmgr 对主库实施停库，备库进而 集群恢复后，尽快执行一次全量备 自动切换。 份。 见续表 96 第 5 章 KINGBASEES 备份恢复 表 5.5.1 – 续表 事件 集群应对行为 备份功能相关 备库存储故障 repmgr 对备库实施停库；若流复制 备库故障不影响备份工作的开展。 配置为同步，或者 quorum 模式下 备节点都故障，主库会转换流复制 为异步模式 (async 或 all 不用处 理)。 5.5.3.5 数据损坏/人为错误 根据指定自然时间点来恢复 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=time --target=’2020-9-21 16: 28:37’ restore 根据指定备份文件集来恢复 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --set 20220518-050250F_20220518051108I --type=time --target='2022-05-18 11:27:21' --delta restore 根据指定 XID 来恢复 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=xid --target=’44556677’ restore 5.5.3.6 响应慢或挂起 如果需要，可以 sys_backup.sh stop 暂停自动备份服务后，处理异常，然后 sys_backup.sh start 启动自动备份 服务。 5.5.4 计划内停机操作 5.5.4.1 补丁、升级 5.5.4.1.1 资源补丁、升级 本备份还原工具 sys_rman 不直接关联其他资源。 升级后，请根据实际需要更新： 97 第 5 章 KINGBASEES 备份恢复 • 初始化配置文件 $bin/sys_backup.conf 如有需要可以重新初始化配置一次，初始化将清理旧的备份文件集。 • 备份还原功能配置文件 $repo_path/sys_rman.conf 5.5.4.1.2 sys_rman 补丁、升级 补丁、升级过程应该避开初始化配置文件固定的凌晨备份时间。 本备份还原工具包含四个文件： • sys_backup.sh 初始化配置脚本，可直接覆盖升级。 • sys_backup.conf 初始化配置文件，可直接覆盖升级。 • sys_rman 备份还原二进制可执行文件，可直接覆盖升级。 • sys_rman.conf 备份还原配置文件，可直接覆盖升级。 注意: sys_rman 兼容旧的备份文件集，新的 sys_rman 将兼容旧版本的 sys_rman 产生的备份文件集。 5.5.4.1.3 停机升级方式 本备份还原工具不需要停机升级。 5.5.4.1.4 在线升级 在线升级过程应该避开初始化配置文件固定的凌晨备份时间。 本工具包含的四个文件均支持在线直接覆盖升级。 5.5.4.1.5 系统或硬件补丁、升级 如果变更需要重启主机或是停止网络等影响资源运行的操作，选择在线升级，否则选择停机升级。 5.5.4.2 配置变更 5.5.4.2.1 sys_rman 配置 请根据实际需要更新： • 初始化配置文件 $bin/sys_backup.conf 如有需要可以重新初始化配置一次，初始化将清理旧的备份文件集。 • 备份还原功能配置文件 $repo_path/sys_rman.conf 98 第 5 章 KINGBASEES 备份恢复 5.5.4.3 增加删除节点 • 增加节点并不直接影响备份还原功能。 • 删除的节点，如果被删除的不是备份服务功能所在节点，不影响。 • 删除的节点，如果被删除的是备份服务功能所在节点， 需要重新选择一个节点，填充初始化配置文件，然后初始化配置。 5.6 非独立备份 非独立备份指的是在现有数据库节点上进行备份还原的操作。 要求具有良好的独立存储通道和充足的存储空间。 5.6.1 配置 5.6.1.1 硬件-限制 备份将额外占用较多的物理存储空间。 推荐配置下大致预估的额外空间：3 倍于实际数据库存储占用空间。 请根据实际项目需求和集群数据文件大小的量级合理设置备份策略和频次。 通用策略推荐的全量备份周期：7 天； 通用策略推荐的增量备份周期：1 天； 通用策略推荐的保留份数：5 份全量备份。 5.6.1.2 硬件-推荐配置 单机请参考: 硬件配置 KingbaseES 读写分离集群请参考: 硬件配置 KingbaseES Clusterware 集群请参考: 硬件配置 5.6.1.3 数据库配置 确保所有主备节点的 archive_mode 均配置为 on. grep archive_mode $db_path/esrep.conf archive_mode = on 99 第 5 章 KINGBASEES 备份恢复 注意: archive_command 将由配置脚本自动填充实际内容。 5.6.1.4 备份还原功能配置 注意: init start 命令要求在 REPO 备份服务器节点上执行。 • 初始化配置时 1 准备初始配置文件 sys_backup.conf 此配置文件模板位于 share 目录下，填充配置完成后可以移动到 $bin_path 目录下。 # 配置文件关键片段 # 指明当前的数据库是单机或者集群，single/cluster _target_db_style=”cluster” # 建议配置数据库的 primary node 的 IP，只需一个 IP 地址 _one_db_ip=”192.168.1.11” # 备份服务器所在的 IP # 主备集群 + 内在备份服务器 设置为等同于$_one_db_ip # 主备集群 + 外部备份服务器 设置外部备份服务器 _repo_ip=”192.168.1.66” _stanza_name=”kingbase” _os_user_name=”kingbase” # 备份文件实际存储路径，注意磁盘容量 _repo_path=”/home/kingbase/back_dir” # 全量备份保留份数 _repo_retention_full_count=5 # 全量备份周期（天数） _crond_full_days=7 # 差异备份周期（天数） _crond_diff_days=0 # 增量备份周期（天数） _crond_incr_days=1 # 自动执行全量备份的时间点，2 表示凌晨 2 点 _crond_full_hour=2 # 自动执行差异备份的时间点，3 表示凌晨 3 点 _crond_diff_hour=3 # 自动执行增量备份的时间点，4 表示凌晨 4 点 _crond_incr_hour=4 # 带宽限制, 单位为 Mb/s, 默认值 0 时无限制 _band_width=0 # 定义指令 100 第 5 章 KINGBASEES 备份恢复 _os_ip_cmd="/sbin/ip" _os_rm_cmd="/bin/rm" _os_sed_cmd="/bin/sed" _os_grep_cmd="/bin/grep" # 单机设置 _single_data_dir=”/home/kingbase/ES/V9/data” _single_bin_dir=”/home/kingbase/ES/V9/Server/bin” _single_db_user=”system” _single_db_port=”54321” # 开启时使用 sys_securecmd, 未开启使用普通 ssh _use_scmd=on 2 执行初始化配置 初始化备份还原功能 $bin/sys_backup.sh init 启动备份还原功能 $bin/sys_backup.sh start 3 确认备份还原功能配置文件 sys_rman.conf cat $repo_path/sys_rman.conf 注意: 要求管理员在 sys_backup.sh init 前，数据库节点与外部备份节点之间以相应的 OS 用户，互相进行 SSH 登 录，以验证 SSH 登录场景，通过 StrictHostKeyChecking 的检测。 • 日常备份时 常规日常备份由系统的 CRONDTAB 触发，不需要额外关注。 如果因为业务需要，可使用如下命令执行一次全量备份。 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=full backup 或者差异备份 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=diff backup 或者增量备份 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=incr backup • 故障还原时 101 第 5 章 KINGBASEES 备份恢复 在数据节点上执行还原动作。 注意: 如果实际备份文集的 $repo_path 遭到了损坏，还原功能将失效。 备份和还原时，工具将自动进行文件级别的有效性校验。 1. 根据不同的故障及场景开展还原 如果是独立外部备份的情况下，数据节点的 $repo_path 已经损坏的情况下，从外部备份节点拷贝 $repo_path/ sys_rman.conf 到数据节点相应目录， 并作出少许修改，详细请参考用户手册。 如果 $data_path 没有任何文件 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name restore 如果 $data_path 有可信赖可保留的文件 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --delta restore 2. 启动刚刚还原的数据节点成为新的 primary node 3. 在其他数据节点执行 repmgr clone 从新的 primary node 克隆节点 $bin/repmgr standby clone -desrep -Uesrep -p-h --fast-checkpoint 5.6.2 监控指标 确认 CRONDTAB 报告备份还原功能 sys_rman cat /etc/cron.d/KINGBASECRON 在 REPO 节点，磁盘剩余多少空间 df -h 在 REPO 节点，确认备份已经消耗了多少磁盘空间 du -h $repo_path 查看已产生备份文件集列表 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name info 102 第 5 章 KINGBASEES 备份恢复 5.6.3 从计划外停机中恢复 因为备份还原功能并不是 24 小时工作，从计划外停机中恢复时，不需要额外的行为。 如果备份文件集发生了损坏，需要尽快进行全量备份来保证至少有一个可用的全量备份。 确认 CRONDTAB 报告备份还原功能 sys_rman cat /etc/cron.d/KINGBASECRON 5.6.3.1 集群还原策略 如果集群中一个节点出现严重问题时，应该采用 repmgr 工具的 clone 功能。 新节点上线后，使用 repmgr 工具接入集群中。 如果集群所有节点都出现严重问题时，应该采用本工具进行还原。 1 选择一个数据库节点，使用还原功能； 2 使用 repmgr 工具 clone 其他节点； 3 整个集群恢复正常工作状态。 5.6.3.2 站点故障 站点故障包括网络原因、电力中断或人为原因导致站点设备停止工作，若没有跨站点的备节点，需要人工恢复集 群 如果故障没有造成存储文件的损坏，按照集群章节的方法恢复集群。 如果故障造成存储文件的损坏，按照本章节的方法还原数据系统。 5.6.3.3 实例或计算机故障 集群主节点发生进程故障、设备断电、设备重启、网络故障 根据集群章节的方法处理， 处理过程应该避开每日备份节点； 或者 sys_backup.sh stop 暂停自动备份服务后，处理异常， 然后 sys_backup.sh start 启动自动备份服务。 集群备机进程故障、设备断电、设备重启、网络故障 备库故障不影响备份工作的开展。 103 第 5 章 KINGBASEES 备份恢复 5.6.3.4 存储故障 集群管理软件会监测数据库存储情况，遇到存储故障的情形会关闭数据库，相关行为如下表 表 5.6.1: 存储故障 事件 集群应对行为 备份功能相关 主库存储故障 repmgr 对主库实施停库，备库进而 集群恢复后，尽快执行一次全量备 自动切换。 份。 repmgr 对备库实施停库；若流复制 备库故障不影响备份工作的开展。 备库存储故障 配置为同步，或者 quorum 模式下 备节点都故障，主库会转换流复制 为异步模式 (async 或 all 不用处 理)。 5.6.3.5 数据损坏/人为错误 根据指定自然时间点来恢复 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=time --target=’2020-9-21 16: 28:37’ restore 根据指定备份文件集来恢复 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --set 20220518-050250F_20220518051108I --type=time --target='2022-05-18 11:27:21' --delta restore 根据指定 XID 来恢复 $bin/sys_rman --config=$repo_path/sys_rman.conf --stanza=$stanza_name --type=xid --target=’44556677’ restore 5.6.3.6 响应慢或挂起 如果需要，可以 sys_backup.sh stop 暂停自动备份服务后，处理异常，然后 sys_backup.sh start 启动自动备份 服务。 104 第 5 章 KINGBASEES 备份恢复 5.6.4 计划内停机操作 5.6.4.1 补丁、升级 5.6.4.1.1 资源补丁、升级 本备份还原工具 sys_rman 不直接关联其他资源。 升级后，请根据实际需要更新： • 初始化配置文件 $bin/sys_backup.conf 如有需要可以重新初始化配置一次，初始化将清理旧的备份文件集。 • 备份还原功能配置文件 $repo_path/sys_rman.conf 5.6.4.1.2 sys_rman 补丁、升级 补丁、升级过程应该避开初始化配置文件固定的凌晨备份时间。 本备份还原工具包含四个文件： • sys_backup.sh 初始化配置脚本，可直接覆盖升级。 • sys_backup.conf 初始化配置文件，可直接覆盖升级。 • sys_rman 备份还原二进制可执行文件，可直接覆盖升级。 • sys_rman.conf 备份还原配置文件，可直接覆盖升级。 注意: sys_rman 兼容旧的备份文件集，新的 sys_rman 将兼容旧版本的 sys_rman 产生的备份文件集。 5.6.4.1.3 停机升级方式 本备份还原工具不需要停机升级。 5.6.4.1.4 在线升级 在线升级过程应该避开初始化配置文件固定的凌晨备份时间。 本工具包含的四个文件均支持在线直接覆盖升级。 5.6.4.1.5 系统或硬件补丁、升级 如果变更需要重启主机或是停止网络等影响资源运行的操作，选择在线升级，否则选择停机升级。 105 第 5 章 KINGBASEES 备份恢复 5.6.4.2 配置变更 5.6.4.2.1 sys_rman 配置 请根据实际需要更新： • 初始化配置文件 $bin/sys_backup.conf 如有需要可以重新初始化配置一次，初始化将清理旧的备份文件集。 • 备份还原功能配置文件 $repo_path/sys_rman.conf 5.6.4.3 增加删除节点 • 增加节点并不直接影响备份还原功能。 • 删除的节点，如果被删除的不是备份服务功能所在节点，不影响 • 删除的节点，如果被删除的是备份服务功能所在节点， 需要重新选择一个节点，填充初始化配置文件，然后初始化配置。 106 第 6 章 KINGBASEES 在线数据定义变更特性 6 第 章 KingbaseES 在线数据定义变更特性 在数据库使用过程中由于业务变更或维护需要，有时会需要改变数据库对象的逻辑或物理结构以支持新的业务特 性或获得更好的性能。 改变对象的结构往往会触发对象数据的重构，过程中为了保持隔离性和一致性也可能会在对象上加高等级的封锁 阻塞在对象上的其他并发操作造成服务中断，在对象的数据容量很大时可能引入很长的停机时间。 KingbaseES 提供一些特性使得这类变更尽可能短的影响业务，特性包括： 1. 并发构建索引 普通的索引创建或重建操作会阻塞对象的修改操作，并发构建索引可以解决这个问题。详情参见产品手册中 CREATE INDEX 说明中的并发构建索引部分。 2. 分区表 ATTACH/DETACH 在普通表中做数据处理然后 ATTACH 到分区表或是通过 DETACH 后 ATTACH 方式替换分区表中的分区可以 实现最小化的业务影响。 详情参见产品手册中 SQL 语言-数据定义-分区中的分区维护部分。 3. 表结构变更 KingbaseES 在删除、增加列时也可以实现在大多数条件下无需立刻重做整个表的数据。适用条件和限制参见产 品手册中 SQL 语言-数据定义-修改表中关于增加列、移除列的说明。 4. 在上述特性不适用的情况下，通用的处理方式是： a. 基于原有对象数据生成变更后的数据。 b. 同时使用实时的逻辑复制保持数据的同步。 c. 阻塞访问，切换新旧数据。 KingbaseES 提供 FlySync 实现实时的逻辑复制。 107 版权声明 版权声明 北京人大金仓信息技术股份有限公司（简称：人大金仓）版权所有，并保留对本手册及本声明的一切权利。 未得到人大金仓的书面许可，任何人不得以任何方式或形式对本手册内的任何部分进行复制、摘录、备份、修 改、传播、翻译成其他语言、将其全部或部分用于商业用途。 免责声明 本手册内容依据现有信息制作，由于产品版本升级或其他原因，其内容有可能变更。人大金仓保留在没有任何通 知或者提示的情况下对手册内容进行修改的权利。 本手册仅作为使用指导，人大金仓在编写本手册时已尽力保证其内容准确可靠，但并不确保手册内容完全没有错 误或遗漏，本手册中的所有信息也不构成任何明示或暗示的担保。 技术支持 • 人大金仓官方网站：http://www.kingbase.com.cn/ • 人大金仓文档中心：http://help.kingbase.com.cn/ • 全国服务热线：400-601-1188 • 人大金仓技术支持与反馈信箱：support@kingbase.com.cn 108 服务周期承诺 服务周期承诺 由于市场需求在不断变化，技术创新和发展的进程不断加剧，产品的版本更迭不可避免。人大金仓对于产品版本 生命周期的有效管理，有助于您提前规划项目，更好地从产品服务终止上过渡。 表 1: KingbaseES 产品生命周期里程碑 关键里程碑点 定义 产品发布日期 产品正式发布版本，即 GA（general availability）版本的发布日期。 停止销售日期 正式停止销售的日期，版本停止接受订单日。该日之后，产品将不再销售。 停止功能升级日期 在该日期之后，不再提供新特性和新硬件支持。但依旧提供错误修复、安全修复、功 能维护等服务。 停止功能维护日期 在该日期之后，不再维护功能，修复问题。但依旧提供安全修复等服务 停止安全维护日期 在该日期之后，不再发布补丁版本修复中高风险漏洞，仅提供有限的支持。 产品服务终止日期 停止提供产品服务和支持的日期。包括软件维护版本，缺陷修复，以及针对该产品的 所有服务支持（包括服务热线和远程/现场支持）。 服务周期策略 金仓数据库管理系统 KingbaseES 产品确保以下的服务周期： 1）产品自发布之日起至产品停止功能升级（包含新特性、新硬件支持）之日不少于 5 年。 2）产品停止功能升级之日起至产品停止功能维护（主要包括问题修复）之日不少于 4 年。 3）产品功能维护停止之日起至产品停止安全维护（包括中高风险漏洞修复）之日不少于 2 年。 服务终止策略 金仓数据库管理系统 KingbaseES 产品确保在销售后，至少提供 6 年的服务支持。 注意: 人大金仓将会综合各方因素来确定产品服务终止日期。并将在实际产品服务终止日期之前至少 90 天，通过公 109 服务周期承诺 开方式宣布产品服务终止日期。 110