KingbaseES数据库运维手册.pdf

KingbaseES 数据库运维手册 金仓数据库管理系统 KingbaseES 文档版本：V9（V009R001C001B0024） 发布日期：2023 年 10 月 12 日 北京人大金仓信息技术股份有限公司 目 目 录 录 第 1 章 前言 1 1.1 适用读者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 相关文档 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 术语 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 手册约定 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 2 章 服务连续性运维 4 2.1 概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 影响服务连续性的典型问题及原因概览 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 造成风险/问题的原因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1.1 站点故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1.2 集群故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1.3 节点故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1.4 网络故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1.5 人为错误 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1.6 资源耗尽 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1.6.1 环境资源耗尽 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1.6.2 数据库资源耗尽 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 风险/问题监控、数据采集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1 概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 监控 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 集群状态类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2.1.1 节点状态 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2.1.2 守护进程状态 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2.1.3 流复制状态 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2.1.4 复制槽 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 资源耗尽类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 环境资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2.2.1.1 存储容量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2.2.1.2 CPU、内存、网络、IO 用量 . . . . . . . . . . . . . . . . . . . . . . . 10 数据库资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 2.3 2.3.2.1 2.3.2.2 2.3.2.2.1 2.3.2.2.2 I 目 录 2.3.2.2.2.1 连接数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2.2.2.2 长事务 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2.2.2.3 事务号使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2.2.2.4 封锁情况 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2.2.2.5 license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 日志 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 数据采集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3.1 日志 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3.2 健康检查 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3.3 集群事件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 风险/问题识别 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.1 概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2 识别 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2.1 集群状态类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2.2 资源耗尽类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 风险/问题溯因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 信息收集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1.1 日志 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1.2 数据库状态检查结果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1.3 其他信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2.3 2.3.3 2.4 2.5 2.5.1 2.5.2 2.5.1.3.1 core dump file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.1.3.2 数据库进程调用栈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.1.3.3 当前活动连接 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 溯因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 集群状态类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 节点状态异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.2.1.1.1 集群中数据库意外关闭 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.2.1.1.2 数据库无法启动（主库或备库） . . . . . . . . . . . . . . . . . . . . . 16 2.5.2.1.1.3 集群故障节点无法自动恢复 . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.2.1.1.4 集群中存在多个主节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 守护进程异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 节点未注册 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 流复制状态异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 缺少 WAL 文件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 复制槽异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.2.1.4.1 复制槽数量、类型异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.2.1.4.2 复制槽活动状态异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 数据库进程无响应 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 数据库进程依赖的 OS 子系统无响应 . . . . . . . . . . . . . . . . . . . 20 资源耗尽类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 环境资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 存储容量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2.1 2.5.2.1.1 2.5.2.1.2 2.5.2.1.2.1 2.5.2.1.3 2.5.2.1.3.1 2.5.2.1.4 2.5.2.1.5 2.5.2.1.5.1 2.5.2.2 2.5.2.2.1 2.5.2.2.1.1 II 目 录 CPU、内存、网络、IO 用量 . . . . . . . . . . . . . . . . . . . . . . . 22 数据库资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.2.2.2.1 连接数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.2.2.2.2 长事务 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.2.2.2.3 事务号使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.2.2.2.4 封锁情况 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.2.2.2.5 license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.2.2.2.6 事务状态访问异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 风险/问题处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.6.1 概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.6.2 影响分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 资源耗尽类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 集群状态类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 集群中数据库意外关闭 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.3.1.1.1 网关故障关库（老版本） . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.3.1.1.2 磁盘故障关库（use_check_disk=on） . . . . . . . . . . . . . . . . . . 27 2.6.3.1.1.3 数据库 coredump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 数据库无法启动（主库或备库） . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.3.1.2.1 检查点（checkpoint）错误 . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.3.1.2.2 时间线（timeline）错误 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.3.1.2.3 配置错误 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 集群故障节点无法自动恢复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.6.3.1.3.1 存在双主（不自动恢复故障节点） . . . . . . . . . . . . . . . . . . . . 28 2.6.3.1.3.2 无法判断节点是备库（recovery=standby） . . . . . . . . . . . . . . . 28 2.6.3.1.3.3 故障节点 TimeLine 更高 . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.3.1.4 集群中存在多个主节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.3.1.5 守护进程异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 节点未注册 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 流复制状态异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 缺少 WAL 文件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 复制槽异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.3.1.7.1 复制槽数量、类型异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.3.1.7.2 复制槽活动状态异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 数据库进程无响应 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 数据库进程依赖的 OS 子系统无响应 . . . . . . . . . . . . . . . . . . . 30 资源耗尽类问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 环境资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.3.2.1.1 存储容量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.3.2.1.2 CPU、内存、网络、IO 用量 . . . . . . . . . . . . . . . . . . . . . . . 32 数据库资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 连接数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5.2.2.1.2 2.5.2.2.2 2.6 2.6.2.1 2.6.3 2.6.3.1 2.6.3.1.1 2.6.3.1.2 2.6.3.1.3 2.6.3.1.5.1 2.6.3.1.6 2.6.3.1.6.1 2.6.3.1.7 2.6.3.1.8 2.6.3.1.8.1 2.6.3.2 2.6.3.2.1 2.6.3.2.2 2.6.3.2.2.1 III 目 录 2.6.3.2.2.2 长事务 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.6.3.2.2.3 事务号使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.6.3.2.2.4 封锁情况 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6.3.2.2.5 license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6.3.2.2.6 事务状态访问异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 第 3 章 数据防丢失运维 35 3.1 概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 影响数据丢失的典型问题及原因概览 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 典型风险及问题表现 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 丢失内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1.1.1 基础数据丢失 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1.1.2 备份数据丢失 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 风险及问题产生的典型原因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.2.1 存储故障 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.2.2 数据损坏 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.2.3 人为损坏 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.2.3.1 误删除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2.2.3.2 配置错误 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 软件缺陷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.2.4.1 数据库软件缺陷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.2.4.2 操作系统软件缺陷 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.2.5 不可预防的损坏或灾难 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.2.6 其他错误 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 小结 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 风险/问题监控、数据采集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.1 监控思路 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.2 具体监控内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.3 数据采集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3.3.1 基础数据采集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3.3.2 备份数据采集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 风险/问题识别 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4.1 基础数据分析识别 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4.2 备份数据分析识别 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 风险/问题溯因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 风险溯源及示例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5.1.1 基础数据访问异常 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5.1.2 物理备份未配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5.1.3 未归档 WAL 累积过多 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.5.1.4 WAL 日志归档失败 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.5.1.5 data 目录设置不当导致备份失败 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.1.6 使用索引时出现 index …contains unexpected zero page at block …故障 . . . . . . . . 48 3.2.1 3.2.1.1 3.2.2 3.2.2.4 3.2.3 3.3 3.4 3.5 3.5.1 IV 3.6 目 录 风险/问题处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.6.1 影响分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.6.2 常见数据故障及问题处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 第 4 章 数据库性能运维 51 4.1 风险/问题监控、数据采集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2 风险/问题识别 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.3 风险/问题溯因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.3.1 信息收集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.3.2 溯因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 风险/问题处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.1 处理方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.2 常见风险问题处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.2.1 慢 SQL 优化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.2.2 并发场景吞吐量低 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4.2.3 响应时间持续上升 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 常用的性能诊断工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5.1 nmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5.1.1 工具获取 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5.1.2 交互模式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5.1.3 后台收集模式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.5.2 KWR、KSH 报告 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.3 sys_stat_activity 视图 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.4 sys_stat_statement 插件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.5 火焰图 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.4 4.5 第 5 章 参考 59 数据库启停 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 单机环境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.1.1.1 具体命令介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.1.1.2 启动过程常见故障及问题处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 集群环境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.1.2.1 具体命令介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.1.2.2 启动过程常见故障及问题处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.1.2.2.1 集群启动“incorrect command permissions for the virtual ip”故障 . . . . . 62 5.1.2.2.2 备节点“node record is inactive”案例 . . . . . . . . . . . . . . . . . . . . . . 63 5.1.2.2.3 集群启动后 repmgr 工具执行出现“--data-directory-config”check 故障 . . . 64 5.1.2.2.4 集群启动出现“双主”案例分析 . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.2 常用数据库与集群参数说明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.3 常用 SQL 命令 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 数据库版本的查询 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3.1.1 查询数据库版本 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3.1.2 查询数据库 build_version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1 5.1.1 5.1.2 5.3.1 V 5.4 5.5 目 录 5.3.2 数据库连接情况 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3.3 查看 license 到期时间 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3.4 查看锁进程及对象 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3.5 kill session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3.6 查看慢 sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3.7 统计不同类型数据库对象数量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3.8 获取对象 DDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3.9 查询表及表行数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3.10 查询包含 lob 字段的表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.3.11 查询分区表及其对应的子分区 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.3.12 无效对象 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 数据库常用命令工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.1 ksql 命令的使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.2 memstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.3 sys_dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 操作系统常用命令 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 查看硬件配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.5.1 5.5.2 5.5.3 5.5.1.1 CPU 信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.5.1.2 MEMORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.5.1.3 存储空间 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.5.1.4 网卡信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.5.1.5 Swapinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.1.6 其它配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 系统配置相关 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5.2.1 操作系统版本 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5.2.2 内核版本 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5.2.3 系统参数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.5.2.4 系统模块 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.5.2.5 资源限制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.5.2.6 Selinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5.2.7 logind.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5.2.8 system.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.5.2.9 IO 调度算法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.5.2.10 SSH 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.5.2.11 防火墙 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.5.2.12 多路径配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.5.2.13 LVM 配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.5.2.14 文件系统类型、参数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.5.2.15 网络配置信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.5.2.16 如何生成 core 文件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 查看系统运行状态 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 内存信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5.3.1 VI 5.6 目 录 5.5.3.2 CPU 利用率 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.5.3.3 操作系统总 IO 大小 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.5.3.4 TOPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.5.3.5 TOPCPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.5.3.6 网络流量信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3.7 文件系统使用率 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3.8 进程内存使用排名 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3.9 系统内存段、信号量使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.5.3.10 操作系统日志（错误信息） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.3.11 crontab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.3.12 core 文件收集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.5.3.13 如何查看 core 文件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 常用集群操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 集群状态查看 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.6.1.1 数据库/守护进程状态 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.6.1.2 集群事件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.6.1.3 流复制状态 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.6.1.4 复制槽 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.6.1 5.6.2 集群节点注册或注销（register/unregister） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.6.3 集群功能暂停或取消暂停（pause/unpause） . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.6.4 集群手动主备切换（standby switchover） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.6.5 备库跟随新主库（standby follow） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.6.6 故障节点恢复为备库（node rejoin） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.6.7 克隆/重做备库（standby clone） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.6.8 手动加载/卸载 VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.6.9 手动新增/删除节点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.6.10 集群节点修改 sshd/sys_securecmdd 端口 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.6.11 集群用户密码修改 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.6.12 查看集群事件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7 5.8 常用的集群诊断工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7.1 一键检查数据库状态工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7.2 日志收集分析工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 软件包安装及升级管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 版权声明 114 服务周期承诺 115 VII 第 1 章 前言 1 第 章 前言 本手册主要描述可用性、性能、安全领域可能在运行维护阶段出现的风险/问题，及如何应对以达到各领域定义 的目标。主要用于指导一线运维人员和用户 DBA 对金仓 KingbaseES 数据库进行有效的运维。如无特别说明，以上 各领域需求、设计和实施过程中的风险/问题将不在此文档中描述。 各领域的运行维护文档组织方式以运行维护中各个行动做章节目录，每个章节描述针对可能产生风险/问题的原 因的行动。可能涉及的章节内容解释如下： 1. 产生风险/问题的原因概览 描述可能导致各领域风险/问题的原因、造成的风险/问题的典型表现。 2. 风险/问题监控、数据采集 针对可能导致风险/问题原因的监控；用于后续识别、溯因的数据采集。 3. 风险/问题识别 根据获取的信息识别风险/问题。 4. 风险/问题溯因 分析造成识别到的风险/问题的原因，分析影响。 将收集到的信息传递给数据库厂商服务人员，由数据库厂商服务人员完成分析。 为了明确风险/问题，可能需要多种在监控阶段或风险/问题识别后收集的信息作为输入。 5. 风险/问题处理 处理风险/问题，包括： 对风险的影响评估 紧急情况下避免风险/问题影响扩大的处理，明确原因后的完整处理。 注意: 本节和第 4 节风险/问题溯因的行为可能在同时发生，没有必然的时间先后顺序。 前言部分包含以下主题： • 适用读者 1 第 1 章 前言 • 相关文档 • 术语 • 手册约定 适用读者 1.1 KingbaseES 数据库运维手册面向所有使用 KingbaseES 的用户，主要是数据库管理员和一线运维人员。 相关文档 1.2 有关文档的更多信息，可访问 KingbaseES 在线文档库 术语 1.3 无 1.4 手册约定 本文档中可能出现“注意、提示、警告、另请参阅”等标志，它们所代表的含义如下： 注意: 用于突出重要/关键信息、最佳实践等。 提示: 用于突出小窍门、捷径等。 警告: 用于传递设备或环境安全警示信息，若不避免，可能会导致设备损坏、数据丢失、设备性能降低或其 它不可预知的结果。 另请参阅: 用于突出参考、参阅等。 以下程序代码书写约定适用于本文档： 2 第 1 章 前言 符号 说明 [] 表示包含一个或多个可选项。不需要输入中括号本身。 {} 表示包含两个以上（含两个）的候选，必须在其中选取一个。不需要输入花括号本身。 | 分割中括号或者花括号中的两个或两个以上选项。不需要输入“|”本身。 ... 表示其之前的元素可以被重复。 斜体 表示占位符或者需要提供特定值的变量。 大写 表示系统提供的元素，以便与用户定义的元素相互区分。除出现在方括号中的元素外，应当按 照顺序逐字输入。当然，部分元素在系统中是大小写不敏感的，因此用户可以根据系统说明以 小写形式输入。 小写 表示由用户提供的元素。 3 第 2 章 服务连续性运维 2 第 章 服务连续性运维 本部分包含以下主题： • 概述 • 影响服务连续性的典型问题及原因概览 • 风险/问题监控、数据采集 • 风险/问题识别 • 风险/问题溯因 • 风险/问题处理 2.1 概述 服务连续性运维的目标是保障需求制定的 RTO 的达成，主要工作是识别并处置风险、问题。 服务连续性整个生命周期中需求、设计和实施过程中的方法、典型方案请参考《高可用概述》及《高可用最佳应 用实践》。本文档描述如无特别说明，均为运行维护阶段的内容。 服务连续性运维文档使用维护过程的各个活动作为目录组织，可能导致停机的原因和这些原因的监控、识别、溯 因、处理是多对多的关系。 服务连续性运维文档包括以下内容： 1. 影响服务连续性的典型问题及原因概览 描述了可能导致停机的各类原因。 注意: 造成停机的原因分为计划外停机和计划内停机（概念请参考《高可用概述》），本文档只覆盖计划外停 机的原因和相关维护工作。 2. 风险/问题监控、数据采集 针对可能导致停机的原因，监控和收集相关信息用于后续的识别、溯因和处理。 4 第 2 章 服务连续性运维 本节的监控项覆盖可能造成风险/问题的原因，监控项和原因为多对多关系。 3. 风险/问题识别 根据获取的信息识别风险/问题。 4. 风险/问题溯因 对已经识别的风险/问题进行分析，分析形成的原因，分析其影响。 可以将收集到的信息传递给数据库厂商服务人员，由数据库厂商服务人员对风险/问题进行分析。 为了更好的对风险/问题进行分析，需要收集监控信息、识别风险/问题后针对性测试的结果。 注意: 和概览中的原因对应，文档中不考虑计划内维护操作作为引发风险/问题的原因。 5. 风险/问题处理 处理风险/问题，包括： 对风险的影响评估 紧急情况下避免风险/问题影响扩大的处理，明确原因后的完整处理。 注意: 本节和【风险/问题溯因】一节的行为可能在同时发生，没有必然的时间先后顺序。 2.2 影响服务连续性的典型问题及原因概览 2.2.1 造成风险/问题的原因 造成停机的计划外原因包括：站点故障、集群故障、节点故障、网络故障、存储故障、数据损坏、人为错误、资 源耗尽。 注意: 以上原因中存储故障、数据损坏两类原因和其他原因中会造成数据丢失并影响服务连续性的问题将在数据防丢 失运维 一节中覆盖。 站点故障的监控、识别、溯因和处理与容灾方案相关，相关内容将在《两地三中心最佳实践》中覆盖。 2.2.1.1 站点故障 站点的定义在本地部署和云部署中不同，可能是：数据中心（data center）、地域（region）或可用区（available zone）。 5 第 2 章 服务连续性运维 站点故障会导致站点内全部服务不可用，典型原因包括：站点范围的断电、网络中断、自然灾害导致的站点无法 运作。 2.2.1.2 集群故障 集群范围的服务不可用，可能包括： • 集群节点故障数量超过容错的范围 • 集群管理软件失效导致集群停机 • 特定失效导致集群同步阻塞 2.2.1.3 节点故障 • 节点硬件故障 • 节点操作系统中数据库依赖的子系统故障 • KingbaseES 实例故障 2.2.1.4 网络故障 网络故障的原因非常复杂，可能由硬件或软件引起，表现也不尽相同。具体包括： • 网络中断 • 端口被屏蔽 • DNS 解析失败 • 网络延迟（高） • 丢包 • 网络分割 网络故障的原因有： • 网卡故障 • 网线脱落 • 交换机、路由器故障 • 防火墙 • 网络拥塞 网络问题可能导致数据库无法提供服务、数据同步失败、双主等问题。 6 第 2 章 服务连续性运维 2.2.1.5 人为错误 从已有的案例总结，典型原因包括： • 误操作 – 错误的关闭/重启集群、数据库、集群守护进程 – 错误的关闭/重启服务器、操作系统、各类硬件设备 • 配置错误 – 集群参数配置错误 – 数据库参数配置错误 – 操作系统参数配置错误或遗漏 – 应用、接口、中间件配置错误 • 恶意数据修改 – 篡改数据 2.2.1.6 资源耗尽 资源耗尽可能导致响应超时、访问挂起、连接失败等影响服务连续性的问题。 2.2.1.6.1 环境资源耗尽 数据库所在环境的资源使用耗尽导致访问失败或超时，常见的包括： • 存储容量 • 存储处理能力 • 内存容量 • CPU 处理能力 • 网络带宽 • 其他 – 文件句柄 – 信号量 – …… 7 第 2 章 服务连续性运维 2.2.1.6.2 数据库资源耗尽 资源使用达到了数据库配置限制或软件限制，导致相关访问失败或超时。常见的包括： • 连接数耗尽 • 事务号耗尽 • 对象封锁冲突 • license 过期 • …… 2.3 风险/问题监控、数据采集 2.3.1 概述 • 监控 针对风险/问题的原因做监控。注意监控项中描述的监控频率是建议值，在条件不允许时可以按实际情况执行。 例如在没有监控工具或脚本的情况下，可以按巡检频率来获取监控数据。 日常监控是非常重要的，一方面意外总是会非预期而至，良好的监控可以在意外来临时及时的预警，通知 DBA 等专业人员处理，避免故障进一步蔓延；另一方面是持续的监控可以尽早的发现可能出现的问题，预测事故未 来发展的严重程度及可能出现的危机结果，以防范于未然。 • 数据采集 采集内容可能不与风险/问题的原因直接对应，但在识别、溯源过程中可能需要这些信息。这些信息需要触发式 或周期性的采集。后续识别、溯源需要的此类数据在这一节覆盖。 2.3.2 监控 2.3.2.1 集群状态类问题 集群故障、节点故障、网络故障和部分人为错误、资源耗尽问题都会表现出集群状态异常，集群状态信息是监控 中重要的监控项。 2.3.2.1.1 节点状态 监控指标：节点状态 监控频率：每 1 分钟 告警值： 8 第 2 章 服务连续性运维 status 列不是 running 状态 upstream 列，不是级联复制情况下不是 primary 的 node_name 不同节点获得的数据不同 # 在存活的数据库节点执行（当前数据库故障则无法查看状态） repmgr cluster show 保留时间：至少一周 2.3.2.1.2 守护进程状态 监控指标：守护进程状态 监控频率：每 1 分钟 告警值： repmgrd 列，不是 running 状态 # 在存活的数据库节点执行（当前数据库故障则无法查看状态） repmgr service status 保留时间：至少一周 2.3.2.1.3 流复制状态 监控指标：流复制状态 监控频率：每 1 分钟 告警值： state 列值不为 streaming sync_state 列和预期不符（配置的同步方式） 复制差距超过预设值 #ksql 连接数据库执行（连接主库查询） # 查询流复制信息 SELECT * FROM sys_stat_replication; # 查询主备流复制差距 select sys_wal_lsn_diff(sys_current_wal_flush_lsn(), replay_lsn) as lsn_lag, * from sys_stat_replication; 9 第 2 章 服务连续性运维 2.3.2.1.4 复制槽 监控指标：复制槽状态 监控频率：每 10 分钟 告警值： 主库复制槽个数、slot_type 列值或 active 列值为预期外 #ksql 连接数据库执行（连接主库或备库查询） # 复制槽信息 SELECT * FROM sys_replication_slots; 2.3.2.2 资源耗尽类问题 2.3.2.2.1 环境资源 2.3.2.2.1.1 存储容量 监控指标： 以下存储用量百分比： 数据（包括各表空间）、WAL、归档、备份 监控频率：每 5 分钟 告警值：用量超过根据业务需要预设的比例 保留时间：至少一周 2.3.2.2.1.2 CPU、内存、网络、IO 用量 监控指标：CPU、内存、网络、IO 用量 监控频率：每 1 分钟 告警值：用量超过根据业务需要预设的比例 保留时间：至少一周 2.3.2.2.2 数据库资源 2.3.2.2.2.1 连接数 监控指标：当前连接数 监控频率：每 5 分钟 告警值：conns 超过 max_connections 的 80% 10 第 2 章 服务连续性运维 SELECT count(*) as conns FROM sys_stat_activity WHERE backend_type IN ('client backend', 'walsender'); 保留时间：至少一周 2.3.2.2.2.2 长事务 监控指标：当前实例中可见的最老事务 监控频率：每小时 告警值：age 超过 2^32 - 30000000 SELECT pid, datname, query, age(backend_xmin) as age FROM sys_stat_activity WHERE backend_xmin IS NOT NULL ORDER BY age(backend_xmin) DESC LIMIT 1; 保留时间：至少一周 2.3.2.2.2.3 事务号使用 监控指标：当前各库的事务号、多事务号使用 监控频率：每小时 告警值：age 或 mxid_age 超过 2^32 –30000000 SELECT datname, age(datfrozenxid), mxid_age(datminmxid) FROM sys_database; 保留时间：至少一周 2.3.2.2.2.4 封锁情况 监控指标：当前等待封锁的进程数量 监控频率：每分钟 告警值：无固定值，根据业务情况设置 SELECT count(*) FROM sys_locks WHERE granted = false; 保留时间：至少一周 2.3.2.2.2.5 license 监控指标：license 剩余有效期 监控频率：每天 告警值：> 0 且 < 30 11 第 2 章 服务连续性运维 SELECT get_license_validdays() AS valid_days; 2.3.2.3 日志 监控指标：数据库、高可用组件（包括配置的一键数据库状态检查）、OS 日志 监控频率：每 5 分钟 告警值：出现警告及以上级别的日志且日志内容不在白名单中 保留时间：至少一周 2.3.3 数据采集 2.3.3.1 日志 内容：数据库、高可用组件（包括配置的一键数据库状态检查）、OS 日志 数据库日志内容参数： log_statement = ‘ddl’ log_autovacuum_min_duration = 600000 保留时长：至少一周。 2.3.3.2 健康检查 内容：配置周期性的一键数据库状态检查并输出结果。频率至少每天。 保留时长：至少一周。 状态检查项中支持监控项的检查，在没有其他监控工具时可以配置检查替代监控工具。 一键数据库状态检查的结果监控和告警值已纳入日志 一节。 2.3.3.3 集群事件 内容：集群事件 通过以下命令行命令获取的数据： # 在存活的数据库节点执行（当前数据库故障则无法查看） repmgr cluster event 12 第 2 章 服务连续性运维 保留时长：至少一周。 示例输出： 2.4 风险/问题识别 2.4.1 概述 风险/问题识别基于监控和数据采集的输入，主要通过以下方式： 1. 阈值告警 监控过程中监控项达到了告警值，例如数据库日志中出现白名单外的 ERROR 信息。 2. 趋势分析 对比一定时间内的多次数据，变化趋势超过预期，例如存储容量在过去一周内增长超过 30%。 3. 经验 历史上接受的风险，例如触发式或周期性的业务高峰即将到来。 2.4.2 识别 2.4.2.1 集群状态类问题 适用阈值告警方法，不适用趋势分析方法。 2.4.2.2 资源耗尽类问题 适用的识别方法如下： 13 第 2 章 服务连续性运维 阈值告警 趋势分析 存储容量 适用 应在一定范围内周期性波动或按一定幅度稳定增长 CPU、内存、网络、IO 用量 适用 应在一定范围内周期性波动 连接数 适用 应在一定范围内周期性波动 长事务 适用 应在一定范围内周期性波动 事务号使用 适用 应在一定范围内周期性波动 封锁情况 适用 应在一定范围内周期性波动 License 适用 不适用 2.5 风险/问题溯因 2.5.1 信息收集 2.5.1.1 日志 操作系统日志、KingbaseES 日志、高可用组件日志是风险/问题溯因的重要信息来源。 集群环境中分析集群状态相关问题时，建议使用 WalMiner 日志逻辑解码工具降低分析难度和时间。 WalMiner 日志逻辑解码工具可对以上日志进行收集、加工、多机日志整合，以自定义匹配的关键内容呈现输 出，去除无用信息，减少分析难度。 具体使用方式参见《WalMiner 日志逻辑解码工具》。 2.5.1.2 数据库状态检查结果 在发生涉及集群状态的风险/问题时，建议在分析前运行一次一键检查工具作为辅助信息。 具体请参见《金仓数据守护集群和读写分离集群使用手册》613 一键检查数据库状态。 2.5.1.3 其他信息 2.5.1.3.1 core dump file KingbaseES 相关组件产生的 core dump file 是溯因的重要信息来源，默认情况下文件生成在数据目录中。 14 第 2 章 服务连续性运维 2.5.1.3.2 数据库进程调用栈 风险/问题发生时，有可能数据库无法响应客户端的请求，此时各类数据库内的监控和采集都有可能失效，通过 os 层面输出的进程调用栈可以帮助定位此类问题。 通过以下命令获得全部 kingbase 进程的调用栈 (for i in `ps -ef | grep kingbase | grep -v grep | awk '{print $2}'`; do pstack $i; done) > pstack.kingbase 注意: 需要在数据库服务器上安装 gdb** 没有安装的情况下可以通过 cat /proc//stack 获取进程的调用栈 2.5.1.3.3 当前活动连接 当 sql 执行超长时间未结束时，需要收集当前活动连接信息：select * from sys_stat_activity; 2.5.2 溯因 风险溯因是指在感知到风险存在时，找到造成风险的直接原因、间接原因和根本原因。 2.5.2.1 集群状态类问题 2.5.2.1.1 节点状态异常 2.5.2.1.1.1 集群中数据库意外关闭 (1) 网关故障关库（老版本） 在故障库的 kbha.log 中出现以下错误： [NOTICE] PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data. --- 10.10.0.1 ping statistics --3 packets tansmitted, 0 received, 100% packet loss, time 2000ms [WARNING] ping host"10.10.0.1" failed [DETAIL] average RTT value is not greater than zero [INFO] stop database … 报错原因： 【简单说明】kbha 进程连续多次 ping 信任网关失败后会关闭当前节点的数据库 15 第 2 章 服务连续性运维 【详细说明】kbha 进程会不断 ping 信任网关，ping 失败会继续重试，一旦连续 reconnect_attempts 次 都失败后，认为当前节点网络异常，会关闭当前节点数据库（2021 年 7 月之前的版本）。 出现场景： 网络异常，导致 kbha 检测信任网关失败。（2021 年 7 月之前的版本） (2) 磁盘故障关库（use_check_disk=on） 在故障库的 kbha.log 中出现以下错误： [ERROR] [thread xx] Failed to check the mount_point_list 6 / 6, all failed [NOTICE] [thread xx] the use_check_disk = on, will stop the database [INFO] stop database … 报错原因： 【简单说明】kbha 连续多次检测数据目录的读写失败，关闭数据库 【详细说明】kbha 进程每隔 60 秒会检测 mount_point_list（默认为空，检测数据目录）目录下的 I/O 状况，如果失败则间隔 10 秒再次检测，连续 mount_check_max_retries（默认 6）次都失败后，关闭数 据库。 检测方式：查看目录的读写权限，创建文件，写入 8k 数据、读取 8k 数据，删除文件。任何一项失败则认为检测 失败。 出现场景： • 磁盘故障 • 业务压力大 I/O 波动，短时间内 kbha 检测失败 (3) 数据库 coredump 在故障库的 sys_log/*中出现以下错误： [PANIC] XXXX Failed process was running XXXX 或 data 目录中出现 core 文件 出现场景： • 软件失效或特定故障 2.5.2.1.1.2 数据库无法启动（主库或备库） (1) 检查点（checkpoint）错误 无法启动数据库的 sys_log/*中出现以下错误： LOG: invalid primary checkpoint record PANIC: could not locate a valid checkpoint record 16 第 2 章 服务连续性运维 报错原因： 【简单说明】控制文件和 wal 日志对应不上，其中一个被篡改了。 【详细说明】数据库启动时，需要从控制文件 sys_control 中记录的 checkpoint 开始 redo。出现此报错的 原因是数据库根据 checkpoint 记录的 LSN 从本地的 WAL 文件中找不到 WAL 日志或者找到的 WAL 日 志不是 checkpoint。 出现场景： 无（正常情况下不应该出现此问题） (2) 时间线（timeline）错误 无法启动数据库的 sys_log/*中出现以下错误： FATAL: requested timeline 6 is not a child of this server's history Latest checkpoint is at 0/C3000058 on timeline 5, but in the history of the requested timeline, the server forked off from the timeline at 0/C2003018 报错原因： 【简单说明】归档或本地 sys_wal 目录下多了一个或多个 history 文件。 【详细说明】数据库启动时会读取 sys_wal 目录下的所有 X.history 文件，并取最高的来判断控制文件中 的 checkpoint 是否合理。X.history 会记录每个时间线 timeline 的结束 LSN，当发现 checkpoint 的 LSN 为 A，而 history 文件中记录对应时间线的结束 LSN 为 B，且 A>B 时，就会认为 checkpoint 是非法的， 就会出现此报错。 出现场景： • 连续多次 PITR 或物理还原（生成了多个 history 文件） • 集群切换后，新主（生成的 history 被归档）重新恢复为备机，之后节点故障恢复 (3) 配置错误 无法启动数据库的 sys_log/*中出现以下错误： 端口被占用 内存超限 不识别的配置项或配置项的值不合法 报错原因： 【简单说明】参数配置不合法或参数配置不合理 出现场景： • 错误的手动修改参数 17 第 2 章 服务连续性运维 2.5.2.1.1.3 集群故障节点无法自动恢复 (1) 存在双主（不自动恢复故障节点） 主库 hamgr.log 中出现以下错误： [ERROR] [thread pid: xx] there may be multiple nodes running as primary, can not do recovery for failed node 报错原因： 【简单说明】出现双主或多主，集群不能执行自动恢复 【详细说明】集群是由主库的 repmgrd 来检测并恢复故障节点。一旦集群中出现多个主库，如果不加限 制，会有多个主库的 repmgrd 对同一个故障节点进行恢复，就会造成集群状态异常，并且可能会损坏故 障节点的数据。所以，当出现多主后，集群不能执行自动恢复。 出现场景： • 网络分隔后恢复，出现双主（最新版本中新主库会关闭老主库） • 手动启动了原主库，出现双主 (2) 无法判断节点是备库（recovery=standby） 主库 hamgr.log 中出现以下错误： [INFO] unable to connect via ES to host "xxxx", can't confirm if it's a standby node [INFO] [thread pid: xx] node (ID: x; host "xxxx") is not attached [INFO] [thread pid: xx] can not do auto-recovery because not confirmed a standby node 报错原因： 【简单说明】recovery=standby 只恢复备库，如果无法确认是否为备库则不恢复。 【详细说明】主库的 repmgrd 会判断 repmgr.nodes 中为 standby 的节点是否需要恢复，如果需要恢复， 就会远程查看该数据库是否真正为备库。会通过 ssh 或 sys_securecmd 远程查看故障数据库是否存在 data/standby.signal 文件，只有确定故障数据库存在该文件才会恢复故障节点。如果远程失败，或者没有 此文件，则不会恢复故障节点。 出现场景： • ssh 或 sys_securecmd 连接失败（日志中有打印：unable to connect via ES to） • 故障节点没有 data/standby.signal 文件（人为删除，或者原来为主库？） (3) 故障节点 TimeLine 更高 主库 hamgr.log 中出现以下错误或者手动执行命令的命令行打印： ERROR: this node's timeline is ahead of the rejoin target node's timeline DETAIL: this node's timeline is 8, rejoin target node's timeline is 7 报错原因： 18 第 2 章 服务连续性运维 【简单说明】故障节点的时间线高于当前主库，为了保护数据不允许继续恢复。 【详细说明】自动恢复或手动恢复（kbha -A rejoin 或 repmgr node rejoin）时，程序会自动判断故障节点 与当前主节点的时间线（TimeLine）和 LSN，如果发现故障节点的 TimeLine 高于当前主库，则认为发生 了数据分歧，继续执行有可能丢失数据，所以会报错退出。 出现场景： • 脑裂后，手动恢复新主库为备库 • 集群所有节点故障，且有多个主库，启动老主库，将其他数据库恢复为备库 2.5.2.1.1.4 集群中存在多个主节点 集群状态 cluster show 结果中 Role 列显示多个 primary： 其他请参考 存在双主不自动恢复故障节点 1 2.5.2.1.2 守护进程异常 2.5.2.1.2.1 节点未注册 在 hamgr.log 中出现以下错误： [ERROR] no metadata record found for this node - terminating [HINT] Check that "repmgr (primary|standby) register" was executed for this node [INFO] repmgrd terminating... 报错原因： 【简单说明】当前节点未注册到集群中。 【详细说明】守护进程 repmgrd 启动时会根据配置文件 repmgr.conf 中记录的节点 ID 从本地数据库中获 取当前节点的信息，如果数据库中的 repmgr.nodes 表中没有当前节点信息，则会报错退出。 出现场景： • 物理备份恢复到了一个比较老的数据版本，当前节点还未注册到集群中 • 本节点被用户手动操作从集群中注销了（使用部署工具删除节点，或命令行执行了 repmgr primary/standby/ witness unregister） • 本节点的配置文件 repmgr.conf 中的 node_id 参数被手动修改为了其他值 • 当前节点是被扩容的新节点，执行了 repmgr standby/witness register 后，新数据还未同步到此节点 19 第 2 章 服务连续性运维 2.5.2.1.3 流复制状态异常 2.5.2.1.3.1 缺少 WAL 文件 备库 sys_log/*中出现以下错误： FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 00000001000003AB00000026 has already been removed 报错原因： 【简单说明】备库需要的 WAL 日志在主库上不存在。 【详细说明】备库启动时会根据 backup_label 文件或者 sys_control 文件开始 redo，本地 WAL 日志 redo 完成后会连接主库拉取 wal 日志。如果主库没有备库需要的 WAL 日志就会返回此报错信息。 出现场景： • 原主库恢复为备库 • 备库 rewind 自动恢复（wal_keep_segments+max_wal_size 配置不合理、长时间未恢复） 2.5.2.1.4 复制槽异常 2.5.2.1.4.1 复制槽数量、类型异常 需要和 DBA 和有权限的用户沟通确认是否是预期行为 2.5.2.1.4.2 复制槽活动状态异常 通常由备机故障或复制状态异常引起 2.5.2.1.5 数据库进程无响应 2.5.2.1.5.1 数据库进程依赖的 OS 子系统无响应 可能表现为无法连接、连接后查询或写入无响应 可能原因常见为 I/O 子系统无响应： 1. 通过 top 获取无响应进程的进程号。使用-c 可以获得进程的 process 描述帮助定位。 2. 确认 top 输出的 S 列值，如果是 D 状态，说明请求在 OS 内核中没有响应。 3. 通过 cat /proc//stack 获取进程的调用栈，协调 OS 工程师进一步做溯因。 4. 非 D 状态的无响应考虑排查资源耗尽类问题。 20 第 2 章 服务连续性运维 2.5.2.2 资源耗尽类问题 2.5.2.2.1 环境资源 2.5.2.2.1.1 存储容量 存储容量超过预期的常见原因包括： 1. 数据（包括各表空间）存储容量不足 a. 残留的临时文件 确认 syssql_tmp 目录容量是否是引起容量不足的原因 b. 表膨胀 参见《表膨胀处理》 c. 过多的性能优化辅助存储结构，例如索引、物化视图 通过存储容量函数确认容量的分布情况，确认排名靠前对象的类型。 d. 业务预期外的增长 通过存储容量函数确认容量的分布情况，和应用接口人共同排查确认是否符合预期。 2. 在线 WAL 存储容量不足 a. 备机故障未及时恢复 通过查看集群状态和复制槽中的 LSN 信息可以确认是否是此类原因。 b. 归档失败导致 WAL 无法被正常回收 数据库日志中会有对应的 archive command failed 日志和执行的具体 command，可以手动执行排查失败的 具体问题。 c. 检查点预期外延迟导致 WAL 无法被正常回收 通过 sys_control_checkpoint() 确认上一次检查点时间，通过 sys_stat_activity 中 checkpointer 的 wait_event 确认目前检查点的等待阶段。通常由 I/O 资源不足引起。 d. 业务峰值或发生不常见的业务操作 通过 waldump 对比预期外增长 wal 和正常 wal 的差异或是 kwr 中的 top sql 对比确认引发 wal 增长的操 作，和应用接口人共同排查确认操作是否符合预期。 3. 归档存储容量不足 a. 备份管理任务没有按预期清理旧备份 备份工具会在备份后清理旧备份和归档，查看备份的保留配置参数是否符合预期；查看备份执行日志确认 清理过程是否报错。 b. 业务峰值或发生不常见的业务操作 同在线 WAL 的排查。 21 第 2 章 服务连续性运维 4. 备份存储容量不足 a. 备份管理任务没有按预期清理旧备份 同归档的排查方式。 b. 数据或 WAL 造成 同数据或 WAL 的排查方式。 2.5.2.2.1.2 CPU、内存、网络、IO 用量 资源用量的溯因参考性能运维的溯因方式。 2.5.2.2.2 数据库资源 2.5.2.2.2.1 连接数 连接数增加常见的原因包括： 1. 业务变化 a. 新增业务模块带来的压力增加 b. 原有业务的规模/用量增加或变化 需要和业务方面接口人确认是否有此情况。 2. 性能或资源原因造成处理能力下降 依赖性能或资源风险/问题的溯因和处理 2.5.2.2.2.2 长事务 引起长事务常见的原因是 1. 各类客户端工具在非自动提交模式下人为操作后未关闭 可以根据 sys_stat_activity 中的 client_addr 和 application_name 判断该事务是否来自客户端工具 2. 应用的特定实现方式或缺陷造成事务未提交 提供 sys_stat_activity 中的 query 和事务中其他语句（如果有日志）给应用接口人排查是否是预期的行为 3. 未结束的两阶段提交事务 查询 sys_prepared_xacts 确认是否是未结束的两阶段提交事务，通过事务名称和应用接口人排查是否是预期的 行为 4. 性能或资源原因造成事务阻塞 依赖性能或资源风险/问题的溯因和处理 22 第 2 章 服务连续性运维 2.5.2.2.2.3 事务号使用 事务号耗尽常见的原因是： 1. 清理回收没有按预期启动 a. 错误的 threshold 相关参数配置 确认自动清理相关参数是否开启 b. 清理速度慢，autovacuum worker 被占用 通过 sys_class 中对象的事务 age 查找到最长 age 的对象，通过 sys_stat_user_tables 确认该对象的自动 清理情况，通过日志中 auto vacuum 信息确认是否有对象长时间占用自动清理工作进程导致其他对象没有 得到自动清理 2. 清理没达到预期效果 a. 存在长事务 溯源方式参见长事务 b. 存在残留的复制槽事务号 查询 sys_replication_slots 确认是否有未预期的 backend_xmin，可能有故障且未恢复的备机或是残留的 slot 2.5.2.2.2.4 封锁情况 封锁超预期的常见原因： 1. 有长时间持有高级别封锁的操作，常见为对象的 DDL 操作 查看数据库日志，确认对应时间内的 DDL 日志。和应用接口人确认是否是预期的行为。 2. 长事务导致事务内封锁未及时释放，常见为阻塞并发的数据更新 溯源方式参见长事务 2.5.2.2.2.5 license license 到期常见原因： 1. 试用版 license 到期 2. 未使用正确的 license 需要确认使用的 license 的预期授权，通过查看 license.dat 文件确认是否和预期相符 2.5.2.2.2.6 事务状态访问异常 常见报错： 23 第 2 章 服务连续性运维 could not access status of transaction xxxx could not open file "sys_xact/xxxx": No such file or directory 信息查看与梳理： 在 ksql 中 show block_size; 查看页面大小。 1. 单机环境 查找 kingbase 日志，以及逻辑备份日志，找到最早报该错误的时间点； 2. 集群环境 查找集群中所有节点的 kingbase 日志，以及逻辑备份日志，找到最早报该错误的时间点； 根据集群中所有节点的 kbha.log 日志、hamgr.log 日志梳理出问题前后集群状态变化情况； 常见原因： 1. xact 不正常情况 a). 新 xact 文件丢失 排查思路: (1). sys_controldata data 目录 | grep NextXID 查看下一个事务 id； (2). 报错的事务 id 与 NextXID 对比，如果相差很大，则不是新 xact 文件丢失问题； (3). 如果相差比较小的话，如果小于 128*block_size，则报错的事务 id 在当前正在写入的 xact 日志 段中，需要排查操作系统日志，是否有存储或内存方面的报错； b). 旧 xact 文件被异常清理 排查思路： (1). 丢失 xact 文件的前后文件均存在，可以查找存储是否有异常信息； (2). 如若存储没有异常，则将相关情况反馈给研发定位分析； 2. xact 正常情况 a). 被 frozen 的数据元组使用 xid 判断可见性 排查思路： (1). 定位报错时正在操作的表对象 1). 查看 kingbase 或逻辑备份日志，找最早报错执行的 sql 并找出 sql 中所涉及的表对象； 2). set synchronize_seqscans to off; 3). 通过 select xmin, xmax, ctid, *from 的查询方式来定位具体是哪个表的问题； (2). 系统表查询 24 第 2 章 服务连续性运维 select relfrozenxid from sys_class where relname = '定位的表对象'； (3). 查看具体 page 页中的元组头信息 1). 创建 pageinspcet 插件； 2). 通过 (1) 中知道具体是在查询哪一行后报了错，来确定报错的这一行的 ctid 值；(比如 (1) 中最后能查到的一行元组的 ctid 为 (X,Y)，则报错的元组的 ctid 的页面号可能为 X 或者 X+1) 3). select t_infomask, * from heap_page_items(get_raw_page(’ 报错的表对象’, 页面号)) where t_xmin = xxxx; 4). select 查询到的 t_infomask & 768; 如果为 768，则该 tuple 有被设置 frozen 标志；否则，没有。 5). 如果是集群环境，排查所有节点的 hamgr.log 日志，查看主库是否对最早出问题的节点执 行过多次故障恢复，是否有多次 rewind 成功，但起库失败的情况； 将以上收集的信息，提供给研发，以便接着分析； b). 数据损坏导致 xid 异常 排查思路： (1). 使用 for i in {1..N}; do printf ’125’; done > xxxx 造丢失的 xact 文件；(N 为 32*block_size) (2). 定位到的出错表的数据可以正常读取，则不是数据损坏的问题；如果不能正常读取，则需要借助 备份重做数据； 2.6 风险/问题处理 2.6.1 概述 处理的目标是在分析评估风险/问题后选择适合的处理方案来避免、减轻或接受风险/问题。不考虑识别后无需处 理的情况，处理方案大致分为两类： 1. 紧急处理：风险/问题经过影响分析后认为可能引起重大问题情况下，在可能不确认原因甚至可能引起其他风 险/问题的情况下对风险/问题的临时处置，避免引起更严重或更大范围的问题。 2. 完整处理：明确风险/问题原因后针对根因的处置方式。 25 第 2 章 服务连续性运维 2.6.2 影响分析 2.6.2.1 资源耗尽类问题 资源完全耗尽后大部分会造成服务中断。影响分析的重点是估算资源消耗趋势和时间。时间允许情况下使用完整 处理方式避免对业务的影响。 2.6.3 处理 以上人为操作引起的后果无法预料且很难追溯，所以尽可能通过工具或脚本进行日常操作，人工操作有条件下加 入复核或记录操作步骤。影响未知的操作前最好进行备份、使用相关安全功能避免和追溯恶意操作。 2.6.3.1 集群状态类问题 2.6.3.1.1 集群中数据库意外关闭 2.6.3.1.1.1 网关故障关库（老版本） 关键错误（kbha.log）： 处理步骤：【恢复网络，恢复节点】 请先和客户确认，是否存在网络波动，后续是否还会出现。 如果集群中无主库存活： 1. 查看集群每个节点状态 ls -l data # 查看 standby.signal 文件，如果有则是备库 sys_controldata -D data # 查看控制文件中的 checkpoint，判断数据量 2. 确认主库（数据量最多），直接启动 sys_ctl -D data start 3. 如果有其他故障主库，手动恢复（恢复前先备份，防止数据丢失） kbha -A rejoin -h ${主库 IP} 4. 等待集群自动恢复 repmgr service status # 查看集群状态，等待恢复 如果集群中有主库存活： 1. 查看故障节点状态 ls -l data # 查看 standby.signal 文件，如果有则是备库 sys_controldata -D data # 查看控制文件中的 checkpoint，判断数据量 2. 如果故障节点和主库无数据差异，可以手动恢复（先备份，防止数据丢失） 3. 如果有其他故障主库，手动恢复（恢复前先备份，防止数据丢失） kbha -A rejoin -h ${主库 IP} 4. 等待集群自动恢复 repmgr service status # 查看集群状态，等待恢复 26 第 2 章 服务连续性运维 2.6.3.1.1.2 磁盘故障关库（use_check_disk=on） 处理步骤：【调整参数】 和客户确认是否磁盘出现问题（可以查看操作系统 message），如果是，请修复磁盘问题。 调整参数： 方法 1：设置 use_check_disk=off，仅检测，检测磁盘故障后不关闭数据库 方法 2：增大磁盘检查次数，设置 mount_check_max_retries=20，防止短时间磁盘 IO 问题导致数据库关闭 2.6.3.1.1.3 数据库 coredump 处理步骤： 请联系人大金仓技术服务人员处理。 2.6.3.1.2 数据库无法启动（主库或备库） 2.6.3.1.2.1 检查点（checkpoint）错误 处理步骤：【重置控制文件中的 checkpoint】 1. 获取控制文件中记录的 WAL file 名称 sys_controldata -D data # 找到第 8 行，记录的 wal file 名称，例如：000000010000000A0000002D 2. 使用 sys_resetwal 重置控制文件（重置后可能会丢失数据） sys_resetwal -l ${WAL file} data # 会自动根据 sys_wal 目录下已有的 wal 文件以及-l 指定的文件，找到一个最大的作为新的 checkpoint 和 wal 文件 3. 启动数据库 2.6.3.1.2.2 时间线（timeline）错误 处理步骤：【删除多余的 history 文件】 1. 获取控制文件中记录的 timeline sys_controldata -D data # 找到第 9 行，记录的 TimeLineID 2. 删除高于控制文件中 TimeLineID 的 history 文件（0000000X.history） 备库和主库 data/sys_wal 目录下 归档（如果是 sys_rman 备份，则位于 repo/archive/xxxx 目录下）目录下 3. 启动数据库 27 第 2 章 服务连续性运维 2.6.3.1.2.3 配置错误 处理步骤：【更正配置】 更正不合法或不合理的配置 2.6.3.1.3 集群故障节点无法自动恢复 2.6.3.1.3.1 存在双主（不自动恢复故障节点） 处理步骤：【消除双主、关闭原主库】 1. 确认多个主库的数据情况，保证要关闭的主库数据较少 备份所有主节点的数据目录 连接到主数据库中，人为判断业务数据 select sys_current_wal_lsn(); 注意：切换时间线时执行 checkpoint 会导致较高时间线的数据库 LSN 大，但是数据并不一 定最新。 2. 如果 recovery=automatic，请先暂停集群 repmgr service pause repmgr service status # 查看是否成功暂停：'Pause?' 列为 yes 3. 关闭其中一个主库（有条件，关闭后可以备份 data） sys_ctl -D data stop 4. 取消集群暂停 repmgr service unpause repmgr service status # 查看是否取消暂停，集群恢复正常：'Pause?' 列为 no 5. （可选）恢复原主库为备库 kbha -A rejoin -h ${新主库 IP} # 如果新主库时间线较低，上面命令可能会失败，请执行以下命令恢复 repmgr node rejoin --force-rewind --no-check-wal -h ${新主库 IP} -U esrep -d esrep -p ${新主库端口} 2.6.3.1.3.2 无法判断节点是备库（recovery=standby） 处理步骤：【解决判断备库失败问题】 如果 ssh 或 sys_securecmd 连接失败： 在主库手动执行 ssh kingbase@[故障节点 IP] date 在主库手动执行 sys_securecmd kingbase@[故障节点 IP] date 查看是否有报错，解决报错问题 如果故障节点没有 data/standby.signal 文件： 1. 确认该节点是否可以直接恢复，是否需要备份（防止数据丢失） 2. 在故障节点创建 data/standby.signal 空文件 touch data/standby.signal 28 第 2 章 服务连续性运维 2.6.3.1.3.3 故障节点 TimeLine 更高 处理步骤：【恢复为备库】 # 请确认故障节点无数据需要找回后再执行 在故障数据库执行以下命令进行恢复 repmgr node rejoin -h ${主库 IP} -U esrep -d esrep -p ${主库端口} --force-rewind --no-check-wal 2.6.3.1.4 集群中存在多个主节点 处理步骤参考 存在双主不自动恢复故障节点 1 2.6.3.1.5 守护进程异常 2.6.3.1.5.1 节点未注册 处理步骤：【强制注册备节点】 repmgr standby register -F 2.6.3.1.6 流复制状态异常 2.6.3.1.6.1 缺少 WAL 文件 关键错误（备库 sys_log/*）： FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 00000001000003AB00000026 has already been removed 报错原因： 【简单说明】备库需要的 WAL 日志在主库上不存在。 【详细说明】备库启动时会根据 backup_label 文件或者 sys_control 文件开始 redo，本地 WAL 日志 redo 完成后会连接主库拉取 wal 日志。如果主库没有备库需要的 WAL 日志就会返回此报错信息。 出现场景： • 原主库恢复为备库 • 备库 rewind 自动恢复（wal_keep_segments+max_wal_size 配置不合理、长时间未恢复） 处理步骤：【重做备库】 1. 在主库执行命令暂停集群功能（防止重做过程中集群操作此节点） repmgr service pause repmgr service status # 查看是否成功暂停：'Pause?' 列为 yes 2. 在备库执行命令重做数据库 29 第 2 章 服务连续性运维 repmgr standby clone -F -h ${主库 IP} -U esrep -d esrep -p ${主库端口} --fast-checkpoint 3. 启动数据库并重新注册为备库 sys_ctl -D data start repmgr standby register -F 4. 取消集群暂停 repmgr service unpause repmgr service status # 查看是否取消暂停，集群恢复正常：'Pause?' 列为 no 2.6.3.1.7 复制槽异常 2.6.3.1.7.1 复制槽数量、类型异常 预期行为情况下：无需处理，但需要注意，手动增加的复制槽在数据库节点切换后需要重新手动创建。 非预期行为情况下：手动恢复复制槽、删除复制槽 恢复集群应有复制槽，注意集群应有的复制槽会在切换后自动重建。 select sys_create_physical_replication_slot('名称'); 删除预期外复制槽 select sys_drop_replication_slot('名称'); 2.6.3.1.7.2 复制槽活动状态异常 修复备机故障或复制状态异常即可自动恢复 2.6.3.1.8 数据库进程无响应 2.6.3.1.8.1 数据库进程依赖的 OS 子系统无响应 OS 内核无响应的进程无法在用户态控制，在确认原因后需要重启 OS 恢复服务 2.6.3.2 资源耗尽类问题 2.6.3.2.1 环境资源 2.6.3.2.1.1 存储容量 存储容量超过预期的处理方式： 1. 数据（包括各表空间）存储容量不足 30 第 2 章 服务连续性运维 a. 残留的临时文件 紧急处理：R6 旧版本可能在数据库 crash 时残留临时文件，根据停机时间和文件的修改时间手动删除残留 的文件。紧急处理不会影响使用，但在下次 crash 时仍可能残留临时文件。 完整处理：更新到 R6 最新版本，数据库在恢复时会自动删除临时文件。 b. 表膨胀 参见《表膨胀处理》 c. 过多的性能优化辅助存储结构，例如索引、物化视图 紧急处理、完整处理：通过视图 sys_stat_user_indexes 的 idx_scan 列确认容量大的索引的使用情况，删 除使用不多的索引；确认物化视图的使用必要性。如果性能优化需要这些辅助存储结构，参照”业务预期 外的增长”处理方式。 紧急处理可能影响使用对象业务的性能。 d. 业务预期外的增长 紧急处理：在可用的其他存储上创建表空间并移动部分表到新表空间；根据业务使用情况，导出部分历史 数据到列存表中压缩存储。 紧急处理可能涉及大量 I/O 操作和对表的封锁影响线上业务。 完整处理：扩容存储容量。 2. 在线 WAL 存储容量不足 a. 备机故障未及时恢复 紧急处理：短时间无法恢复备节点的情况下，手动删除复制槽。 紧急处理会造成备节点需要通过重建方式恢复。 完整处理：恢复备节点后检查点回收。 b. 归档失败导致 WAL 无法被正常回收 紧急处理：修改 archvie_command 为空并重载配置，WAL 将归档成功并被检查点回收。 紧急处理会造成归档不连续，影响基于 PITR 的备份能力。 完整处理：修复归档失败的问题，自动归档 WAL 并回收。 c. 检查点预期外延迟导致 WAL 无法被正常回收 紧急处理：cancel 部分造成 I/O 压力的操作确保检查点得到足够的资源。 紧急处理会导致对应的业务请求失败。 完整处理：优化产生意外 I/O 压力的操作。 d. 业务峰值或发生不常见的业务操作 紧急处理：无 完整处理：根据新场景重新评估调整检查点参数或扩容存储。 31 第 2 章 服务连续性运维 3. 归档存储容量不足 a. 备份管理任务没有按预期清理旧备份 紧急处理：手动通过 sys_rman 清理备份和归档。 完整处理：修复备份的定时任务。 b. 业务峰值或发生不常见的业务操作 同在线 WAL 的处理 4. 备份存储容量不足 a. 备份管理任务没有按预期清理旧备份 同归档的处理 b. 数据或 WAL 造成 同数据或 WAL 的处理 2.6.3.2.1.2 CPU、内存、网络、IO 用量 资源用量的处理参考性能运维的处理方式。 2.6.3.2.2 数据库资源 2.6.3.2.2.1 连接数 连接数增加的处理方式： 1. 业务变化 a. 新增业务模块带来的压力增加 b. 原有业务的规模/用量增加或变化 紧急处理：如果有，释放部分业务连接池占用但没有实际使用的连接。否则需要调整最大连接数参数。 紧急调整最大连接数需要重启数据库服务。 完整处理：根据新业务模式调整连接数总量或各业务的连接池参数。 2. 性能或资源原因造成处理能力下降 依赖性能或资源风险/问题的溯因和处理 2.6.3.2.2.2 长事务 长事务处理方式 32 第 2 章 服务连续性运维 1. 各类客户端工具在非自动提交模式下人为操作后未关闭 紧急处理：终止对应的连接。 完整处理：调整空闲连接自动断开参数避免此类问题发生。 2. 应用的特定实现方式或缺陷造成事务未提交 紧急处理：取消或终止对应的连接。 紧急处理可能造成应用异常。 完整处理：修复缺陷后更新应用版本。 3. 未结束的两阶段提交事务 紧急处理：回滚两阶段提交事务。 紧急处理可能导致业务逻辑的错误。 完整处理：确认业务的逻辑后处理遗留事务，修复遗留两阶段事务的业务缺陷。 4. 性能或资源原因造成事务阻塞 依赖性能或资源风险/问题的溯因和处理 2.6.3.2.2.3 事务号使用 事务号耗尽处理方式： 1. 清理回收没有按预期启动 a. 错误的 threshold 相关参数配置 b. 清理速度慢，autovacuum worker 被占用 紧急处理：确认 age 最长的对象 如果不是临时表，手动对对象执行 VACUUM FREEZE VERBOSE，如果还不生效，排除可能的封锁进程后 VACUUM FULL。VACUUM FULL 可能阻塞业务。 如果是临时表，取消或终止使用临时表的进程。操作可能造成被取消/终止的业务受影响。 完整处理：参照《表膨胀处理》调整参数，确认长期使用临时表的业务，增加 session 内对临时表的清理操作。 2. 清理没达到预期效果 a. 存在长事务 处理方式参见长事务 b. 存在残留的复制槽事务号 紧急处理：短时间无法恢复备节点的情况下，手动删除复制槽。 紧急处理会造成备节点需要通过重建方式恢复。 完整处理：恢复备节点后检查点回收。 33 第 2 章 服务连续性运维 2.6.3.2.2.4 封锁情况 封锁超预期处理方式： 1. 有长时间持有高级别封锁的操作，常见为对象的 DDL 操作 紧急处理：取消或终止对应的操作。 紧急处理可能造成应用异常。 完整处理：确认对应操作的合理性，变更操作方式或时间段。 2. 长事务导致事务内封锁未及时释放，常见为阻塞并发的数据更新 处理方式参见长事务 2.6.3.2.2.5 license license 到期处理方式： 1. 试用版 license 到期 紧急处理：一般已处于无法启动状态，找到其他可使用的试用 license 替换后启动。 完整处理：申请新 license 替换使用。 2. 未使用正确的 license 紧急处理：一般已处于无法启动状态，找到正确的 license 或其他可使用的试用 license 替换后启动。 完整处理：使用正确的 license 替换。 2.6.3.2.2.6 事务状态访问异常 正常处理：如果有备份，则使用备份进行恢复； 紧急处理：如果没有备份，则可以创建一个事务状态都是” 已提交” 的日志文件，具体的创建方法：for i in {1..N}; do printf ’125’; done > xxxx (xxxx 为报错找不到的日志文件名，N 为 32*block_size) 34 第 3 章 数据防丢失运维 3 第 章 数据防丢失运维 本部分包含以下主题： • 概述 • 影响数据丢失的典型问题及原因概览 • 风险/问题监控、数据采集 • 风险/问题识别 • 风险/问题溯因 • 风险/问题处理 3.1 概述 数据防丢失运维的目的是保障项目的 RPO 目标达成，大部分情况下目标是保证数据和故障灾难前保持一致，即 RPO�0。 3.2 影响数据丢失的典型问题及原因概览 3.2.1 典型风险及问题表现 3.2.1.1 丢失内容 3.2.1.1.1 基础数据丢失 主要指数据库基本数据丢失或损坏，无法找回。 数据丢失或损坏从物理层面可以分为： • Data 目录/表空间 35 第 3 章 数据防丢失运维 • 文件 – 控制文件 – 数据文件 – 密钥文件 – Redo 文件 • 数据块 – 表页面 – 索引页面 数据丢失或损坏从逻辑对象可以分为： • database 数据库 • 表 当我们的生产数据库因为各种原因导致基础数据丢失后，可以通过后备数据库来接管并提供完整数据。如果没有 备数据库，那么只有通过备份数据进行恢复。 3.2.1.1.2 备份数据丢失 备份数据是数据安全最后的保证，一旦生产数据库、备数据库都无法提供完整数据之后，只能通过备份数据来尝 试恢复完整数据。备份数据分为： • 逻辑备份 • 物理备份 逻辑备份比较灵活，但很难保证能够恢复完整数据，主要原因有备份时间长，需挑选备份对象，只能恢复到备份 点等因素。 一般我们通过物理备份 + 归档 WAL 日志 + 在线 WAL 日志来恢复完整数据，所以，一旦备份数据丢失，或者 WAL 日志丢失，那么无法恢复完整数据。 3.2.2 风险及问题产生的典型原因 3.2.2.1 存储故障 存储故障主要考虑： • 磁盘或闪存驱动器故障 • 磁盘控制器故障 • 存储阵列故障 • 磁盘物理损坏 36 第 3 章 数据防丢失运维 由于数据是持久化在存储上的，存储故障基本上都会导致数据大范围的丢失。 3.2.2.2 数据损坏 此类场景一般存在于数据已经进行了持久化，但是后期发生了数据篡改，与存储也有一定的关系。 数据损坏主要考虑： • 已修改的块，与 kingbase 期望找到的不同 a. 物理 i. 无法识别 ii. 校验错误 iii. 全零 b. 逻辑 i. 通过了物理块校验，但逻辑上可能不一致 • 写丢失或误写 a. 写入 IO 未在持久存储上发生，但返回完成，后续读取返回旧版本，更新数据库其他块 b. 写入 IO 已完成，但写入其他地方，后续读取返回旧版本 3.2.2.3 人为损坏 3.2.2.3.1 误删除 误删除场景有 • 逻辑删除 a. 通过 SQL 等业务操作逻辑删除或更新了数据，导致数据丢失或损坏。 • 物理删除 a. 通过命令行例如 rm -rf 物理操作误删除了数据文件或目录。 3.2.2.3.2 配置错误 配置错误场景有 • 配置了错误的数据存储路径。 • 配置了错误的数据库参数导致数据库无法保证数据可靠。 • 配置了错误的操作系统参数导致数据丢失。 • 未配置备份，导致无备份数据。 37 第 3 章 数据防丢失运维 3.2.2.4 软件缺陷 3.2.2.4.1 数据库软件缺陷 数据库软件缺陷一般会由官方定期的发布一些产品补丁，在用户所使用的版本上打入 patch。 已知修复过的的数据库软件缺陷有： • 执行计划缺陷导致数据丢失。 • 事务隔离性缺陷导致数据损坏或丢失。 • 并发执行缺陷导致临界区问题。 • 重复多次恢复导致数据不一致。 • 未选择同步节点进行故障自动转移。 • 脑裂后自动恢复将数据丢弃。 3.2.2.4.2 操作系统软件缺陷 操作系统软件缺陷，一般也会由 OS 厂商定期发布一补丁，在用户所使用的版本上打入 patch。 已知的一些国内 OS 软件缺陷有： • Fsync 数据丢失。 • 数据落盘出错。 • 读数据异常 • 网卡传输队列异常。 3.2.2.5 不可预防的损坏或灾难 自然或不可抗力因素： • 断电 • 地震、火灾等 3.2.2.6 其他错误 • 系统服务异常终止。 • 自动备份被异常终止。 • 磁盘满。 38 第 3 章 数据防丢失运维 小结 3.2.3 数据丢失问题通常由硬件引发，硬件设备自身的缺陷或者硬件老化都可能会引发数据丢失的问题；另外，软件功 能欠缺或缺陷也会引发数据丢失，因此需要关注操作系统、数据库等关键软件厂商发布的产品加固补丁，及时安装对 应的软件补丁；最后，不可控的自然灾害也会导致数据丢失。因此，周期性的对数据进行备份是预防数据丢失最重要 的手段。 数据丢失类问题有时比较难以察觉，因此掌握一定的运维手段和运维步骤便于快速的定位和解决问题/隐患。 3.3 风险/问题监控、数据采集 日常监控是非常重要的，一方面意外总是会非预期而至，良好的监控可以在意外来临时及时的预警，通知 DBA 等专业人员处理，避免故障进一步蔓延；另一方面是持续的监控可以尽早的发现可能出现的问题，预测事故未来发展 的严重程度及可能出现的危机结果，以防范于未然。 3.3.1 监控思路 通过两个方面去监控： • 基础数据 – 数据库各目录是否完整 – 数据库核心文件是否缺失 – 数据库文件块是否异常 – 数据库运行状态 – 数据库配置参数 – 服务器 CPU 状态 – 服务器内存状态 – 服务器磁盘状态 • 备份数据 – 操作系统配置 – 自动备份任务 – 备份参数 – 备份服务器 CPU 状态 – 备份服务器内存状态 – 备份磁盘状态 39 第 3 章 数据防丢失运维 3.3.2 具体监控内容 • 监控丢失内容 • 监控服务器硬件指标 40 第 3 章 数据防丢失运维 41 第 3 章 数据防丢失运维 3.3.3 数据采集 3.3.3.1 基础数据采集 名称 单机/集群 节点物理资源 描述 • CPU/内存大小/磁盘剩余空间/磁盘最大读写速度/网络 带宽 CPU 型号 • 操作系统版本 • 是否专用机 • 是否线上环境 • 是否涉密 • 数据库版本 • 数据库大小写敏感 • 数据库数据页大小 block_size 通信工具 ssh/sys_securecmdd 是否开启归档 • 是否定期逻辑备份 • 是否定期物理备份 • 数据全量大小 • 42 数据日增量大小 • 第 3 章 数据防丢失运维 3.3.3.2 备份数据采集 名称 描述 单机/集群 • 本地备份/远端备份 • 备份节点物理资源 CPU/内存大小/磁盘剩余空间/磁盘最大读写速度/网络 带宽 物理备份策略 全量备份周期/增量备份周期/备份集保留策略 是否独立备份服务器 备份磁盘是网络挂载的还是本地硬盘 确定配置项的生效值 配置项 配置项说明 查看方式 wal_level 需要 replica 或 logical 级 ksql 执行“show wal_level;”获取或者查看 kingbase.conf 文件确定 别，重启生效 archive_mode 需要 on 状态，重启生效 ksql 执行“show archive_mode;”获取或者查看 kingbase.conf 文 件、es_rep.conf 文件确定 archive_command sys_backup.sh init 时自动 设置 data_directory 数据库 data 目录 ksql 执行“show archive_command;”获取或者查看 kingbase.conf 文件、es_rep.conf 文件确定 ksql 执行“show data_directory;”获取 1. 收 集 所有节 点 （包括 主 备 节 点、 存储节 点） 的 kbbr_repo/ sys_rman.conf 配置信息， 以及 存 储节 点 内 kbbr_repo/backup/kingbase/backup.info、kbbr_repo/archive/kingbase/archive.info 文件内容信息 2. 收集 sys_rman info 命令（参考：/home/kingbase/cluster/project/custer/kingbase/bin/sys_rman --config=/ home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase info）的输出，下图为 info 命令正常的输出示例 43 第 3 章 数据防丢失运维 3. 收集 sys_rman check 命令（参考：/home/kingbase/cluster/project/custer/kingbase/bin/sys_rman --config=/ home/kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase check）的输出，下图为 check 命令正常的输出示 例 4. 收集数据库服务器日志内的 archive-push 相关日志，查看归档是否成功，参考命令：grep -rn ”archive-push” data/sys_log 5. 收集数据库服务器的控制信息，参考命令：sys_controldata -D data 6. 如果是 sys_rman restore 有问题，需要额外收集以下信息 配置项 说明 恢复后，启动前的 data 目录内的 backup.label 该文件指明了还原的基础数据信息 恢复后，启动前的 data 目录内的 kingbase.auto.conf 该文件指明了启动后的恢复目标点等信息 启动后的数据库服务器日志 • 44 第 3 章 数据防丢失运维 3.4 风险/问题识别 3.4.1 基础数据分析识别 名称 分析 单机/集群 单机出现单点故障时，无法继续提供服务，且有可能丢 失数据。 节点物理资源 物理资源是否能继续维持良好的数据库服务环境 CPU 型号 不同 CPU 型号兼容性有差异 操作系统版本 不同操作系统、不同版本之间存在兼容性差异 是否专用机 • 是否线上环境 • 是否涉密 • 数据库版本 不同的数据库版本支持的功能有差异 数据库大小写敏感 • 数据库数据页大小 block_size 通信工具 ssh/sys_securecmdd 是否开启归档 物理备份必须开启归档 是否定期逻辑备份 减小数据丢失风险 是否定期物理备份 减小数据丢失风险 数据全量大小 全量数据大小影响物理全量备份时间、备份集保留策略 数据日增量大小 增量数据大小影响物理增量备份时间、增量备份周期等 crontab 服务 物理备份策略依赖 crontab 服务 防火墙 独立备份节点和数据节点直接需要互联 45 第 3 章 数据防丢失运维 3.4.2 备份数据分析识别 sys_rman check 命令（参考：/home/kingbase/cluster/project/custer/kingbase/bin/sys_rman --config=/home/ kingbase/kbbr_repo/sys_rman.conf --stanza=kingbase check）的输出没有报错信息，那么 sys_rman 的配置和归档 是正常的，如下图所示： 3.5 风险/问题溯因 3.5.1 风险溯源及示例 3.5.1.1 基础数据访问异常 参考风险/问题溯因 用户某张表的访问报错，提示 block 块出现问题。 直接原因：数据库访问特定对象故障。 间接原因：是否仅有此对象故障，是否出现大面积坏块。 根本原因: 可能由于操作系统层面、或磁盘问题导致写入磁盘异常，数据丢失或损坏，需要根据现象排查多重日 志，最后发现根本原因是硬盘出现坏道或其他损坏，需要进行返厂维修。 3.5.1.2 物理备份未配置 对下图的错误进行风险溯源 直接原因：没有配置 sys_rman 间接原因：没有配置 sys_rman 根本原因：没有配置 sys_rman，配置 sys_rman 物理备份，具体操作方式参考《物理备份恢复工具手册》 46 第 3 章 数据防丢失运维 3.5.1.3 未归档 WAL 累积过多 直接原因：物理备份工具 sys_rman 在开启每一次物理备份之前，检查数据库中的未归档 WAL 日志的容量，如 果超过了设置的阈值，报错退出。 间接原因：物理备份开始时，将执行一次 sys_switchwal() 来强制产生新的 WAL 文件，并在备份结束时等待此 WAL 文件实际归档到备份目录中。如果未发现此 WAL 文件，备份过程报错并终止。 根本原因：因为物理备份工具支持 PITR，需要持续的 WAL 归档文件，因此工具预先对未归档的 WAL 文件的 总容量进行检查，避免在异常情况下开启不完整的物理备份。 3.5.1.4 WAL 日志归档失败 直接原因：WAL 文件没有在设置的时间范围内归档到备份工具指定的归档目录中。 间接原因： 1. kingbase 的 archive_mode 或 archive_command 配置有误 2. kingbase 处于业务繁忙阶段，未能及时归档 WAL 日志 根本原因： 因为备份工具 sys_rman 支持 PITR 功能，需要持续的、不间断的 WAL 日志文件。 kingbase 在归档 WAL 时，顺序性的、串行的逐个文件进行归档。 确保 archive_mode 为 on，确保 archive_command 由 sys_rman 工具的 archive_push 命令构成且全路径 指定工具 sys_rman 和配置文件 sys_rman.conf； 不在业务繁忙阶段进行物理备份。 47 第 3 章 数据防丢失运维 3.5.1.5 data 目录设置不当导致备份失败 直接原因：如图所示，kingbase 启动时指定了相对目录，导致物理备份不能正常启动。 间接原因：物理备份工具 sys_rman 对比从配置文件获得 kingbase 的 DATA 目录和从数据库的 SQL 接口获取 到的 DATA 目录，如果不一致，就报错退出。 根本原因：因为物理备份具有特殊性，备份产生的备份集作为存档，被使用的场景和主机都具有不确定性。物理 备份集支持在不同的物理主机或者不同的原始目录进行还原，因此不支持使用相对目录启动数据库实例。 3.5.1.6 使用索引时出现 index …contains unexpected zero page at block …故障 直接原因： 在使用索引时，读入内存中的页面为全零页面。 间接原因： 由于硬件系统的原因导致写入外存中的页面或者是读入内存中的页面为全零页面，下面将通过实际举例展 示如何查看全零页面。 1. 查看目标索引是否成功创建 test=# \di 2. 创建并使用 pageinspect 插件（插件的具体使用方法详见 KingbaseES 插件参考手册 pageinspect）查 看内存 buff 中读入的页面是否为全零页面 test=# CREATE EXTENSION pageinspect; SELECT get_raw_page::text FROM get_raw_page('index', 1); 其中’index’为目标索引，1 为要查看的内存中的页号，页面号的值可以在错误信息中找到。 3. 如果上述步骤读入内存中的页面是全零页面，那么记录下页面号，找到目标索引的 relfilenode 再通过 relfilenode 找到目标索引在 data 目录下的位置，然后使用 Linux 命令 hexdump 查看外存中索引文件 中的目标页面并确认目标页面是否在写入外存时就已经发生损坏变成全零页面 以下将分步展示查看外存页面的步骤： 3.1. 计算段号 segNo 48 第 3 章 数据防丢失运维 segNo = pageNo * pageSize / segSize（注：结果向下取整） 在上述公式中 segNo 代表着段号，在 KingBaseES 中数据是存储在一个或多个文件中的，每一个保存数据 的文件被称为段，段号就代表了存放页面的文件的序号。 pageNo 代表了页面号，页面号在报错信息中记录。 pageSize 代表了页面大小，可以通过下面的命令获取它的值： ..code: test=# show block_size; block_size -----------8192 segSize 代表的是段容量，每个段的容量大小是固定的 1048576KB。 3.2. 计算起始地址 start start = pageNo * pageSize - segNo * segSize 由于在外存中数据是通过文件的形式存储的，所以你需要使用 hexdump 命令查看目标文件，但是在一个 文件中又存储了大量的页面，为了只看你关心的目标页面，你需要计算该页面的起始地址。 3.3. 找到目标文件 test=# SELECT relfilenode,relname FROM pg_class; 在得到必要的参数后下一步就是需要找到你要查看的文件，文件在路径 bin/base/目标数据库 oid/ 下，使 用以上示例命令，通过观察 relname 可以找到你要查看的索引的 relfilenode。 文件的命名方式为 relfilenode.segNo，但是有一种特殊情况就是当段号为 0 时文件仅以 relfilenode 命名。 例如文件 13521 就是 relfilenode 为 13521 的第 0 段文件，而文件 13521.2 就是 relfilenode 为 13521 的第 2 段文件。 3.4. 查看目标文件 查看文件需要使用 Linux 的 hexdump 命令，命令的格式为：hexdump -s start -n pageSize filename 在上述命令中 <-s start>代表了文件的起始地址。<-n pageSize> 代表了输出的内容的大小，由于你只需要看一个页面所以只需要输出一个页面的大小就可 以。 示例： hexdump -s 8192 -n 8192 16426 49 第 3 章 数据防丢失运维 上述示例的含义为我要查看文件 16426 从 8192 地址开始往后 8KB 的内容。 4. 最后确认上述结果后在 kingbase.conf 中配置 trace_mdwrite 参数为 on，trace_mdwrite_level 参数 为 all，重新创建索引再查看 sys_log 日志 trace_mdwrite_level 参数有三个级别分别为 valid、non-zero、all，代表含义分别为追踪无效页面，追踪 全零页面，追踪无效页面和全零页面。 将 trace_mdwrite_level 参数置为 all 则可以保证创建索引时系统写入的页面的页头既有效又不为全零， 如果二者之中有一个条件不符合，那么在 sys_log 文件中将存在相应的日志记录。 在查看日志发现没有相应日志记录之后再次执行上述步骤，确定是在写入外存还是在读入内存时发生页面 出现全零现象。 根本原因： 存储数据的磁盘受损，应当考虑更换磁盘重启数据库服务器，重新创建索引，再次尝试使用。 为避免页面受损出现全零页面应当保证做出以下要求： 1. 使用可靠的数据存储磁盘。 2. 完善灾备系统对数据做好充分地备份，以减少甚至避免硬件故障产生的损失。 3.6 风险/问题处理 3.6.1 影响分析 在数据丢失后首先要做的是第一时间找回丢失的数据，降低应用访问异常时间。 具体参见《KingbaseES 物理备份恢复最佳实践》。 其次是保留可能的现场，为后续追溯原因提供环境。 3.6.2 常见数据故障及问题处理 sys_rman 常 见 备 份 还 原 问 题 处 理， 请 参 见 公 司 官 网 手 册：https://help.kingbase.com.cn/stage-api/profile/ document/kes/v9/html/highly/highly-tools/backup/sys-rman-6.html sys_rman 常 见 备 份 失 败 原 因 及 处 理: https://docs.qq.com/doc/DWnNyVmJ6eVVUTGNq?u= 4a3102e3adf64d35adde0bccab89b609 50 第 4 章 数据库性能运维 4 第 章 数据库性能运维 KES 的性能设计可参考《KingbaseES 数据库性能调优指南》第一部分。 本部分包含以下主题： • 风险/问题监控、数据采集 • 风险/问题识别 • 风险/问题溯因 • 风险/问题处理 • 常用的性能诊断工具 4.1 风险/问题监控、数据采集 监控指标：CPU、内存、网络、IO 用量、磁盘 监控频率：每 1 分钟 保留时间：至少一周 建议工具：nmon 监控指标：KWR、KSH 中包括的数据库性能数据 监控频率：每小时一个快照（KSH 不用设置快照时间） 保留时间：至少一周 数据库监控工具：KWR、KSH 操作系统监控方法参见《KingbaseES 数据库性能调优指南》中“3.2 操作系统资源分析”章节，nmon 工具的使 用方法可以直接参见本文nmon 章节。 数据库监控方法参见《KingbaseES 数据库性能调优指南》中“3.3.5 自动负载信息库 SYS_KWR”以及“活跃 会话历史报告 SYS_KSH”章节。 51 第 4 章 数据库性能运维 4.2 风险/问题识别 针对上文中收集到的数据，使用分析工具生成趋势、报告： • 操作系统资源数据分析：nmon analyzer • 数据库资源数据分析：KWR、KSH 报告 操作系统数据分析方法参考《KingbaseES 数据库性能调优指南》中“3.2.1.2 CPU 资源分析”和“3.2.2.2 内存资 源分析”、“3.2.3.2 IO 资源分析”、“3.2.4.2 网络资源分析”章节。 数据库资源数据分析参考《KingbaseES 数据库性能调优指南》中“3.3.5.7 查看 SYS_KWR 报告”、“3.3.6.4 查看 SYS_KSH 报告”章节。 1. 可以通过监控项值的阈值和生成的报告识别风险/问题，具体如下表： 分类 子类 风险/问题识别 操作系统 CPU 利用率超过 70% 利用率快速上涨 % System 过高 IO 利用率超过 50% 网络 利用率超过 50% 网络存在丢包和报错情况 数据库 内存 内存空闲少于 10% 或存在 swap 情况 等待事件 等待时间超过 5% 事务 回滚比例超过 20% 事务 事务执行时间过长 SQL SQL 执行时间过长 4.3 风险/问题溯因 4.3.1 信息收集 收集已有的性能数据或执行收集操作获得最新数据并生成报告，包括： 1. CPU、内存、网络、IO 用量、磁盘监控信息 2. KWR、KSH 中包括的数据库性能数据 在问题发生过程中或复现过程中收集： 52 第 4 章 数据库性能运维 1. 火焰图热点函数信息 火焰图的收集方法参见火焰图 ；分析方法请咨询 KingbaseES 的支持人员。 4.3.2 溯因 针对风险/问题的溯因方式如下表： 分 子 类 类 操 CPU 风险/问题识别 溯因 利用率超过 70% 重点关注火焰图和 KWR 报告中的 TOP SQL 部分 作 利用率快速上涨 系 % System 统 IO 利用率超过 50% pidstat/iotop 查看操作系统 io 分布 KWR 报告，重点关注 IO Profile 网 利用率超过 50% 通过 nethogs/iftop 查看操作系统网络分布 络 网络存在丢包和报错 返回行数与网络资源消耗存在直接关系，可通过查看 KWR 报告中（根据 情况 返回行数的 TOP SQL）报告排查问题 内 内存空闲少于 10% 或 top 查看内存使用以及数据库内存配置 存 存在 swap 情况 数 等 等待事件超过 5% 查看 KWR、KDDM 报告中等待事件相关部分 据 待 库 事 回滚比例超过 20% 分析运行日志与应用 事务执行时间过长 分析运行日志确认事务中执行时间长的 SQL，参考《KingbaseES 数据库 件 事 务 事 务 SQL SQL 调优指南》优化 SQL SQL 执行时间过长 分析运行日志确认 SQL，参考《KingbaseES 数据库 SQL 调优指南》优化 SQL 具体分析方法参见《KingbaseES 数据库性能调优指南》的“第二部分性能诊断”章节以及《KingbaseES 数据库 SQL 调优指南》的“4.3 分析执行计划”章节。 53 第 4 章 数据库性能运维 4.4 风险/问题处理 4.4.1 处理方法 处理方法参见《KingbaseES 数据库性能调优指南》的“第三部分性能优化”章节以及《KingbaseES 数据库 SQL 调优指南》的“第 5 章 SQL 优化手段”章节。 在性能调优到最佳状态，风险/问题仍然存在时，可以通过扩展瓶颈资源方式处理，例如： 1. 纵向扩展：例如扩容存储、增加内存容量、增加更高效的存储、增加处理器核数 2. 横向扩展：例如增加只读副本并均衡负载到副本 4.4.2 常见风险问题处理 4.4.2.1 慢 SQL 优化 执行计划分析 + 火焰图，参考《KingbaseES 数据库性能调优指南》 4.4.2.2 并发场景吞吐量低 收集问题时间段的 nmon、KWR 报告、火焰图，参考《KingbaseES 数据库性能调优指南》 4.4.2.3 响应时间持续上升 在响应时间指标对比明显的两个时刻下，分别收集 nmon、KWR 报告、火焰图，分析关键指标的差异，尤其是 时间模型的数据差异。 4.5 常用的性能诊断工具 4.5.1 nmon nmon 是一种在 AIX 与各种 Linux 操作系统上广泛使用的监控与分析工具。它能在系统运行过程中实时地捕捉 系统资源（CPU、IO、内存、网络等）的使用情况，记录的信息比较全面。 在通过 nmon 完成采样后，可以通过 nmon 的 spreadsheet analyze 来找出当时的性能监控数据，并下载 nmon analyzer，在 excel 中离线查看当时的性能监控数据。 54 第 4 章 数据库性能运维 4.5.1.1 工具获取 nmon：nmon for Linux | Site / Download (sourceforge.net) nmon analyzer：nmon for Linux | Site / Nmon-Analyser (sourceforge.net) 4.5.1.2 交互模式 直接通过./nmon 启动。 通过 help 中的快捷键选择需要实时显示的信息 55 第 4 章 数据库性能运维 4.5.1.3 后台收集模式 后台收集模式是通过采样的方式收集一段时间内的操作系统资源使用情况，并输出一个特定的文件，并可利用 excel 分析工具（nmon analyser）进行数据的统计分析。 56 第 4 章 数据库性能运维 使用示例： • 信息收集：./nmon -f -t -s 10 -c 100 -m /home/kingbase/nmon/ • 可视化数据：通过 nmon analyzer 导入 nmon 文件即可生成可视化报告 4.5.2 KWR、KSH 报告 参考《KingbaseES 数据库性能调优指南》中“3.3.5 自动负载信息库 SYS_KWR”章节以及“3.3.6 活跃回话历 史报告 SYS_KSH”章节。 4.5.3 sys_stat_activity 视图 参考《KingbaseES 数据库性能调优指南》中“3.3.2.1 活跃会话连接”章节。 4.5.4 sys_stat_statement 插件 参考《KingbaseES 数据库性能调优指南》中“3.3.1.1 使用 sys_stat_statement 工具”章节。 4.5.5 火焰图 火焰图使用步骤： 1）下载工具，上传到数据库服务器 57 第 4 章 数据库性能运维 git clone https://github.com/brendangregg/FlameGraph.git # or download it from github 2）用 root 用户，进入到工具文件夹 cd FlameGraph 3）选择想要采集的时间启动 perf 记录数据， perf record -F 99 -a -g 4）等到想要采集的数据足够多时（如 1 分钟左右），ctrl+c 结束 perf record 命令，可以看到 perf.data 就是生 成的记录结果 5）生成火焰图 perf script | ./stackcollapse-perf.pl > out.perf-folded ./flamegraph.pl out.perf-folded > perf-kernel.svg 把火焰图拍照或导出。 58 第 5 章 参考 5 第 章 参考 本部分包含以下主题： • 数据库启停 • 常用数据库与集群参数说明 • 常用 SQL 命令 • 数据库常用命令工具 • 操作系统常用命令 • 常用集群操作 • 常用的集群诊断工具 • 软件包安装及升级管理 5.1 数据库启停 5.1.1 单机环境 5.1.1.1 具体命令介绍 • 启动数据库，通过 sys_ctl 命令启动数据库 sys_ctl start -D /home/kingbase/KingbaseES/V9/data • 关闭数据库 通过 sys_ctl –D data 路径 stop 命令关闭数据库，如下： sys_ctl -D /home/kingbase/KingbaseES/V9/data stop 59 第 5 章 参考 若关闭成功，“waiting for server to shut down …. Down”的提示。通过 ps –ef|grep kingbase 不能查看到 kingbase 对应的进程。 • 重启数据库 通过 sys_ctl –D data 路径 restart 重启数据库，如下： sys_ctl -D /home/kingbase/KingbaseES/V9/data restart 若重启成功，有“waiting for server to shut down …done”以及“server started”的提示。 sys_controldata -D data 路径，查看 Time of latest checkpoint: 行最新时间。 数据库启动后，可通过 ps -ef | grep kingbase 查看启动数据库启动是否成功，如下图： 若启动成功，能够看到有“xxx/bin/kingbase –D …”，该进程是必不可少的，还有类似“kingbase: logger”的 辅助进程。以及如图所示 checkpointer 检查点进程 walwriter，background writer 后台进程等，这些后台进程是数据 库正常活动必不可少的。这里一定要体现出来。 其中启动命令示例中的/home/kingbase/KingbaseES/V9/data 为数据库 data 路径，每个数据库的 data 路径可 能不一致。data 路径的查看方法： • 通过进程（已启动情况下） ps -ef | grep kingbase 注意: 含 xxx/Server/bin/kingbase -D ... 一行，-D 后为 data 所在绝对路径或者相对于启动路径的相对路径 • 通过参数（已启动情况下） ksql -USYSTEM -d TEST -c "show data_directory;" • 通过文件（未启动情况下） find / -name kingbase.conf 60 第 5 章 参考 注意: 查找含 data 路径的，如有多个，可根据控制文件确定 启动过程常见故障及问题处理 5.1.1.2 在关闭数据库的过程中，一直在提示“wait for server to shutdown….” 原因： 1. 数据库此时有可能在将 buffer 中的脏数据库刷盘，此时是正常现象。“wait for server to shutdown…”提示一 段时间后，数据库成功关闭 2. 若“wait for server to shutdown…”提示后，一直没有关闭数据库，此时数据库可能有异常（如一个事务一直 没有结束等），请联系运维人员。 5.1.2 集群环境 5.1.2.1 具体命令介绍 KingbaseES 集群的启停管理通过 sys_monitor.sh 脚本实现，此脚本可以集群任意节点执行。 (1) sys_monitor.sh 脚本使用 [kingbase@node101 bin]$ pwd /home/kingbase/cluster/R6HA/kha/kingbase/bin [kingbase@node101 bin]$ ./sys_monitor.sh --help Usage: ./sys_monitor.sh {start|stop|restart|stoplocal|set [--restart]|change_password user password} (2) 启动集群 [kingbase@node101 bin]$ ./sys_monitor.sh start (3) 停止集群 [kingbase@node101 bin]$ ./sys_monitor.sh stop (4) 停止本节点的服务（包括集群管理和数据库服务，一般用于备库） [kingbase@node101 bin]$ ./sys_monitor.sh stoplocal (5) 重新启动集群 61 第 5 章 参考 [kingbase@node101 bin]$ ./sys_monitor.sh restart 5.1.2.2 启动过程常见故障及问题处理 5.1.2.2.1 集群启动“incorrect command permissions for the virtual ip”故障 故障现象： 在使用 sys_monitor.sh start 启动集群时出现以下故障 问题分析： 对于集群主库 vip 地址的加载，需要使用 arping 工具执行 arp 缓存的清理和 ip 地址占用的测试，如果 arping 工 具出现版本不兼容及权限问题，将导致在主库加载 vip 地址失败。 • 查看 arping 配置 (repmgr.conf)： arping_path='/home/kingbase/cluster/R6C5/R6C5R/kingbase/bin' • 查看 arping 版本信息： [kingbase@node101 bin]$ ./arping -V arping utility, iputils-s20210301kb • 查看 arping 权限 [kingbase@node1 bin]$ ls -lh arping -rwxr-xr-x 1 kingbase root 11K Nov 5 2021 arping 注意: 对于通用机环境 arping 属主应该是 root 用户，由于需要 kingbase 用户可以执行此工具，因此需要增加 se- tuid。 62 第 5 章 参考 问题解决： 配置 arping 权限 [root@node3 ~]# cd /home/kingbase/cluster/R6C5/R6C5R//kingbase/bin [root@node3 bin]# chown -R root.root arping [root@node3 bin]# chmod u+s arping [root@node3 bin]# ls -lh arping -rwsr-xr-x 1 root root 11K Nov 5 2021 arping 配置 arping 权限后，重新执行 sys_monitor.sh 启动集群，问题解决。 问题总结： 对于 kingbaseES 集群使用数据库系统自带的 arping 软件包，一般不会出现版本不兼容的问题；对于 arping 工具 的属主应该是 root，不是 kingbase 用户，但为了 kingbase 用户也能执行 arping，必须配置 arping 的 setuid 权限。 5.1.2.2.2 备节点“node record is inactive”案例 故障现象： 集群在启动后，查看集群节点状态信息，如下所示：standby 节点状态为“inactive”。 问题分析： 对于 repmgr 集群中，节点为“inactive”状态时，需要从以下几个方面进行检查分析： a. 查看数据库进程启动是否正常（主备库的状态） b. 查看数据库 sys_log 日志，是否有复制槽（slot）等故障信息。 c. 查看数据库 sys_log 日志，是否有 timeline 等故障信息。 通过对 standby 节点以上信息检查，没有发现错误。 问题解决： 在备库执行“repmgr standby register --force”后，查看集群节点状态，standby 节点状态恢复正常。 问题总结： 63 第 5 章 参考 对于 repmgr 集群“node record is inactive”问题，一般是因为 standby 节点数据库服务或流复制出现问题，节 点注册集群失败，导致集群状态显示为“inactive”，根据错误日志分析，一般处理的思路可以按照以下步骤: a. 执行‘repmgr standby register –force’，问题解决，无需执行下一步。 b. 执行‘repmgr node rejoin’，问题解决，无需执行下一步。 c. 执行‘repmgr standby clone’。 5.1.2.2.3 集群启动后 repmgr 工具执行出现“--data-directory-config”check 故障 故障现象： 在执行‘repmgr standby switchover’时，出现以下故障： ERROR: “data_directory” parameter in repmgr.conf on “”is incorrectly configured 问题分析： a. 检查 repmgr.conf 文件中 data_directory 变量的配置。 b. 使用‘repmgr node check --data-directory-config‘检查变量。 c. 检查数据库进程启动 -D 指定数据库文件存储路径，发现数据库启动路径采用了相对路径。 问题解决： 重新启动集群，数据库服务启动时 -D 后路径应使用绝对路径，问题解决。 问题总结： 在使用 sys_ctl 手工启动集群主备节点的数据库服务时，应该在‘-D’参数后使用绝对路径，不要使用相对路 径，避免在执行 repmgr 工具或 sys_rman 备份时，出现故障。 5.1.2.2.4 集群启动出现“双主”案例分析 适用版本：V9（所有版本） 故障现象： 集群在启动过程中，出现“双主”的故障，对于“双主”故障，需要人工参与，判断集群中那个节点是最新的主 库，重新恢复集群。 如下图所示，集群节点状态显示：node249 为集群主节点（primary），node248 为集群备节点（standby），但 是数据库启动为主库状态。 64 第 5 章 参考 问题分析： 此故障一般当集群主机掉电重启或 failover 切换后，原主库没有正常被降为备库，加入集群。对于此类问题可以 采用以下步骤处理： a. 查看主备库数据库服务进程，是否正常启动了数据库服务。 b. 通过控制文件对比两个“主库”之间的 timeline、checkpoint 的 lsn 及事务 ID，通常选择更新的时间线、lsn 记 录或事物 ID 确定最新的主库。但是对于生产环境，需要通过业务数据来确定最新的主库。 [kingbase@node101 bin]$./sys_controldata -D data c. 确定最新主库后，可以将另外的节点重新加入集群。 问题解决： a. 确定新主库后，将备库节点重新 rejoin，作为 standby 加入集群。 b. 测试主备流复制状态及集群状态。 c. 确定主备库数据安全。 详见:refs:‘存在双主不自动恢复故障节点 “ 问题总结 对于集群“双主”或“脑裂”问题，要人工及时发现并介入处理，首先要确定集群最新的主库节点，对于 生产环境，应该以业务数据作为首选项，然后将另外的节点，作为 standby 节点重新加入集群。 当系统启动防火墙、节点间网络阻塞、备库 data 目录下缺少 standby.signal 文件等，启动集群后都有可能 导致“双主”问题复现，因此在启动集群前，需要做对应的检查。 5.2 常用数据库与集群参数说明 请参见《金仓数据守护集群和读写分离集群使用手册》集群配置说明。 65 第 5 章 参考 5.3 常用 SQL 命令 • DDL：《KingbaseES SQL 语言参考手册》 • DCL：《KingbaseES SQL 语言参考手册》 • DML：《KingbaseES SQL 语言参考手册》数据操作 5.3.1 数据库版本的查询 5.3.1.1 查询数据库版本 select version(); 5.3.1.2 查询数据库 build_version select build_version(); 5.3.2 数据库连接情况 查看支持的最大连接数量： Show max_connections; 查看所有连接状态： select * from sys_stat_activity; 关闭连接： Select sys_terminate_backend(pid); 注意: sys_terminate_backend(pid)：1) 需要 superuser 权限，可以关闭所有的后台进程；2) 向后台发送 SIGTERM 信号，关闭事务、关闭 Process。 66 第 5 章 参考 5.3.3 查看 license 到期时间 select get_license_validdays(); 5.3.4 查看锁进程及对象 通过系统目录 sys_locks、sys_stat_activity 去查看。 5.3.5 kill session 1. 通过”ps –ef|grep kingbase” 命令查看 KingbaseES 的所有进程，除辅助进程外的其它进程为 session 对应的进 程 2. 找出想要杀死的 session 对应的进程 ID，通过输入“kill -9 + 想要杀死的进程 ID”，如下图： 3．再次通过“ps –ef|grep kingbase”查看 session 对应的进程 ID 是否杀死，如下图： 67 第 5 章 参考 5.3.6 查看慢 sql • 方法一： 1. 在 kingbase.auto.conf 配置文件中配置如下参数，如果有 SQL 执行时间超过 1000ms，会把执行的 SQL 语 句记录在日志中。 Log_min_duration_statement=1000 Log_statement='mod' 2. 重启数据库生效 • 方法二 执行 SQL 命令（需要超级用户权限）： set Log_min_duration_statement=1000; set Log_statement='mod'; 5.3.7 统计不同类型数据库对象数量 Table,view,sequence,function,procedure,package,packagebody,materialized view,type,type body 等。 • 获取表的数量，通过 select count(*) from sys_class where relkind='r' or relkind='t' or relkind='f' or relkind='p'; 其中‘r’表示普通标，’t’表示 TOAST 表，‘f’表示外部表，’p’表示分区表 • 获取视图数量，通过 select count(*) from sys_class where relkind='v'; 获取视图数量 68 第 5 章 参考 • 获取 sequence 数量，通过 select count(*) from sys_class where relkind='S'; 获取 sequence 的数量 • 获取 function 数量，通过 select count(*) from sys_proc where prokind='f' or prokind='a' or prokind='w'; 获取 function 的数量 • 获取 procedure 数量，通过 select count(*) from sys_proc where prokind='p'; 获取 procedure 的数量 • 获取 type 数量，通过 select count(*) from sys_type; 获取 type 数量。 69 第 5 章 参考 5.3.8 获取对象 DDL 1. 创建插件 dbms_metadata 2. 执行 SQL 命令‘select dbms_metadata.get_ddl(’table’,’t1’);’ **注意：**以上操作需要超级用户权限。 5.3.9 查询表及表行数 通过命令： select relname, reltuples from sys_class cls left join sys_namespace N ON (N.oid = CLS.relnamespace) where nspname NOT IN ('sys_catalog', 'information_schema') AND cls.relkind = 'r' order by reltuples desc; 如下图： 70 第 5 章 参考 5.3.10 查询包含 lob 字段的表 通过如下命令查询包括 lob 字段的表 select relname from sys_class,sys_attribute,sys_type where sys_class.oid = sys_attribute.attrelid and sys_ attribute.atttypid=sys_type.oid and sys_type.typname like '%lob'; 5.3.11 查询分区表及其对应的子分区 1. 通过‘d’命令查看当前数据库的所有表，通过类型一列查看该表是否为分区表 2. 对于分区表，通过 d+ 表名查看对应的子分区，如下图： 5.3.12 无效对象 通过命令： 71 第 5 章 参考 select count(*) from sys_class where reloptions='{status=false}'; 获取无效对象的个数 5.4 数据库常用命令工具 5.4.1 ksql 命令的使用 登录数据库：ksql -U 用户名 -W 数据库名 登录数据库之后可做如下操作： • 退出登录：q • 查看数据库列表：l • 查看默认模式下所有表的名称：dt • 查看某个表的结构：d table_name • 查看元命令帮助信息：? 5.4.2 memstat 参见 memstat 5.4.3 sys_dump 参见 sys_dump 72 第 5 章 参考 5.5 操作系统常用命令 5.5.1 查看硬件配置 5.5.1.1 CPU 信息 cat /proc/cpuinfo lscpu | grep -E "Architecture|^CPU\(s\)|^CPU MHz|Model name" 5.5.1.2 MEMORY cat /proc/meminfo [root@dbhost03 ~]# cat /proc/meminfo MemTotal: 4770676 kB MemFree: 1994604 kB MemAvailable: 4076664 kB Buffers: 2224 kB Cached: 2262668 kB SwapCached: 0 kB Active: 492420 kB Inactive: 1849180 kB Active(anon): 80428 kB Inactive(anon): 46604 kB Active(file): 411992 kB Inactive(file): 1802576 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2097148 kB SwapFree: 2097148 kB Dirty: 24 kB Writeback: 0 kB AnonPages: 76728 kB Mapped: 86792 kB Shmem: 50324 kB Slab: 229464 kB 73 第 5 章 参考 SReclaimable: 152424 kB SUnreclaim: 77040 kB KernelStack: 6416 kB PageTables: 11300 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 4482484 kB Committed_AS: 1024280 kB VmallocTotal: 34359738367 kB VmallocUsed: 198252 kB VmallocChunk: 34359310332 kB HardwareCorrupted: AnonHugePages: # 当前已经申请的内存，并不表示已分配 0 kB 4096 kB CmaTotal: 0 kB CmaFree: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 122688 kB DirectMap2M: 2899968 kB DirectMap1G: 2097152 kB # 大页空间，如果启用大页。 free -m 注意: 如果想查看内存型号、主频等信息，可以用 dmidecode | grep -P -A200 ”Memorys+Device” | more 命令。 5.5.1.3 存储空间 • 文件系统空间使用率 df -m 74 第 5 章 参考 • 文件系统 inode 使用率 df -i • 磁盘信息 fdisk -l | grep -i disk ls -l /dev/disk/by-uuid 75 第 5 章 参考 • 多路径信息 multipath -ll • 文件系统类型 mount 5.5.1.4 网卡信息 ifconfig -a 76 第 5 章 参考 ethtool 网卡名 77 第 5 章 参考 5.5.1.5 Swapinfo • 查看 swap 使用情况 swapon -s free -m 78 第 5 章 参考 5.5.1.6 其它配置 lspci 5.5.2 系统配置相关 5.5.2.1 操作系统版本 cat /etc/system-release 5.5.2.2 内核版本 uname -a 79 第 5 章 参考 5.5.2.3 系统参数 sysctl -a 5.5.2.4 系统模块 列出所有已加载的模块： lsmod modprobe -l 列出系统已经编译的模块（redhat7 已经没有 list 选项），或者用如下命令查看 80 第 5 章 参考 ls /lib/modules/`uname -r`/kernel 5.5.2.5 资源限制 ulimit -Ha 用户的进程个数限制： cat /etc/security/limits.d/*conf 81 第 5 章 参考 5.5.2.6 Selinux cat /etc/selinux/config | grep ^SELINUX 5.5.2.7 logind.conf cat /etc/systemd/logind.conf 82 第 5 章 参考 5.5.2.8 system.conf 83 第 5 章 参考 cat /etc/systemd/system.conf 5.5.2.9 IO 调度算法 ls /sys/block/|while read diskname; do fdisk -l /dev/$diskname >& /dev/null; test $? -eq 0 && (echo -n " 磁盘 $diskname : " ; cat /sys/block/$diskname/queue/scheduler); done 84 第 5 章 参考 5.5.2.10 SSH 配置 cat /etc/ssh/ssh_config 85 第 5 章 参考 86 第 5 章 参考 5.5.2.11 防火墙 systemctl status firewalld.service 87 第 5 章 参考 5.5.2.12 多路径配置 cat /etc/multipathd.conf|grep -v '^#'|grep -v '^$' 88 第 5 章 参考 5.5.2.13 LVM 配置 lvs pvs vgs 5.5.2.14 文件系统类型、参数 mount 89 第 5 章 参考 5.5.2.15 网络配置信息 cat /etc/sysconfig/network-scripts/ifcfg-网卡名 90 第 5 章 参考 如何生成 core 文件 5.5.2.16 以 Centos7 为例： 1. 确认针对用户的 core 文件大小没有限制。 ulimic –c 2. 修改/etc/abrt/abrt-action-save-package-data.conf 文件，并重启 abrtd 服务（如果不行，重启服务器）。 OpenGPGCheck = no ProcessUnpackaged = yes 3. 确认/var/spool/abrt 目录下有生成 ccpp* 之类的文件。 5.5.3 查看系统运行状态 5.5.3.1 内存信息 sar -r 2 2 91 第 5 章 参考 5.5.3.2 CPU 利用率 sar -u 2 2 5.5.3.3 操作系统总 IO 大小 iostat 2 2 92 第 5 章 参考 5.5.3.4 TOPIO iotop -b -k -P -n 4 93 第 5 章 参考 5.5.3.5 TOPCPU top -o %CPU -i -b -n 4 94 第 5 章 参考 5.5.3.6 网络流量信息 sar -n DEV 2 2 5.5.3.7 文件系统使用率 df -m 5.5.3.8 进程内存使用排名 ps auxc --sort=-%mem | more 95 第 5 章 参考 5.5.3.9 系统内存段、信号量使用 ipcs --human -a 96 第 5 章 参考 5.5.3.10 操作系统日志（错误信息） systemctl | more 97 第 5 章 参考 5.5.3.11 crontab cat /etc/cron.d/* cat /var/spool/cron/* 98 第 5 章 参考 5.5.3.12 core 文件收集 ls -l /var/spool/abrt 5.5.3.13 如何查看 core 文件 core 文件创建在什么位置？ 在当前进程的工作目录下创建，通常与程序在相同的路径下。但如果程序中调用了 chdir 函数，则有可能改变了 当前工作目录。这时 core 文件创建在 chdir 指定的路径下。Redhat7 使用 abrtd （automatically bug report daemon） 服务，core 文件会在/var/spool/abrt/ccpp* 目录下。 使用 gdb 分析 kingbase 生成的 core 文件。 gdb kingbase 二进制路径 core 文件路径 进入交互界面后 bt 显示堆栈，bt full 显示包括参数值的堆栈 5.6 常用集群操作 5.6.1 集群状态查看 5.6.1.1 数据库/守护进程状态 命令行命令： # 在存活的数据库节点执行（当前数据库故障则无法查看状态） repmgr cluster show repmgr service status cluster show 查看要点： • Status 列，正常应该是 * running 或 running 状态； • Upstream 列，如果不是级联复制，都是指向主库，应该显示 primary 的 node_name； 99 第 5 章 参考 service status 查看要点： • repmgrd 列，正常应该是 running 状态； • Paused? 列，正常应该是 no 状态； 注意: 如果不同节点看到的状态不同，表示集群状态异常。典型场景是 primary 宕机，standby 接管的情况。 5.6.1.2 集群事件 命令行命令： # 在存活的数据库节点执行（当前数据库故障则无法查看） repmgr cluster event 可以看到事件及事件发生时间，可以辅助定位问题。 5.6.1.3 流复制状态 SQL 语句： 100 第 5 章 参考 #ksq 连接数据库执行（连接主库查询） # 查询流复制信息 select sys_wal_lsn_diff(sys_current_wal_flush_lsn(),replay_lsn) as lsn_lag,client_addr,state, sent_lsn,write_lsn,flush_lsn,replay_lsn,sync_state,sync_priority from sys_stat_replication; 流复制信息查看要点： • lsn_lag 列，表示主备流复制差距； • state 列，显示为 streaming 的表示数据同步状态为正常状态； • sync_state 列，显示为 sync 的为同步备库，显示为 quorum 的为优先同步备库（其中一个是同步），显示 potential 或 async 为异步备库； esrep=> select sys_wal_lsn_diff(sys_current_wal_flush_lsn(),replay_lsn) as lsn_lag,client_addr,state, esrep-> sent_lsn,write_lsn,flush_lsn,replay_lsn,sync_state,sync_priority from sys_stat_replication; lsn_lag | client_addr | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | sync_state | sync_ priority ---------+-----------------+-----------+----------+-----------+-----------+------------+------------+-------------0 | 192.168.237.102 | streaming | | 0/7000820 | 0/7000820 | 0/7000820 | quorum | 0 | 192.168.237.103 | streaming | | 0/7000820 | 0/7000820 | 0/7000820 | quorum | 1 1 (2 行记录) 5.6.1.4 复制槽 SQL 语句： #ksq 连接数据库执行（连接主库或备库查询） # 复制槽信息 select * from sys_replication_slots; 查看要点： • slot_type 列，集群使用都是物理复制槽（physical）； • active 列，显示为 t 的是正在使用的复制槽，显示为 f 的当前未使用； • xmin 列，未使用的复制槽（active 列为 f）此列可能为空，如果此列不为空会影响数据库 VACUUM 清理死元 组以及阻止 WAL 日志文件回收； esrep=> select * from sys_replication_slots; slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_ xmin | restart_lsn | confirmed_flush_lsn ---------------+--------+-----------+--------+----------+-----------+--------+------------+------+-------------+-------------+--------------------- 101 第 5 章 参考 repmgr_slot_2 | | 0/7000820 | | | f | t | 7232 | 1089 | | physical | | | f | f | | | repmgr_slot_3 | | | physical | | (2 行记录) 5.6.2 集群节点注册或注销（register/unregister） 命令行命令： # 在对应的数据库节点执行 # 注册或注销备库 repmgr standby register/unregister [--force] # 注册或注销主库 # 注册主库：集群中无存活主库 # 注销主库：（一般不使用）注销故障主库或注销当前主库（集群中无其他数据库） repmgr primary register/unregister [--force] # 注册或注销 witness repmgr witness register/unregister [--force] register 和 unregister 操作通过修改 repmgr.nodes 表信息，将节点的配置信息写入到 repmgr.nodes 表： • register 主要用于手动增加节点，repmgr.conf 配置文件修改（如：priority）后重载，或者节点 inactive 状态情 况下强制注册。 • unregister 主要用于节点的删除操作，比如 standby 节点的删除，或者是异常状态 (多个 primary) 的下 primary 节点删除。 举例如下： 1. 备库注销：standby unregister 2. 备库注册：standby register 102 第 5 章 参考 3. 强制备库注册：standby register --force 5.6.3 集群功能暂停或取消暂停（pause/unpause） 命令行命令： # 在存活的数据库节点执行（集群正常状态下执行） repmgr service pause/unpause pause 命令可以暂停集群的重要功能，主要是自动故障切换（failover）和自动故障恢复（recovery）。例如，在 参数 failover=’automatic’ 情况下，用户因为维护需要手动停止 primary 数据库，集群会自动故障切换，备库升主。 如果用户不希望集群因维护操作而切换，可以将集群置于 pause 状态，待维护操作完成后，再通过 unpause 命令恢复 集群的自动故障切换（failover）和自动故障恢复（recovery）。 103 第 5 章 参考 5.6.4 集群手动主备切换（standby switchover） 命令行命令： # 在备节点执行 # 当前备库变为主库，原主库变为备库 repmgr standby switchover [--force-rewind] [--siblings-follow] 参数说明： • --force-rewind，原主库切换为备库过程中，是否使用 sys_rewind 保证数据一致 • --siblings-follow，其他备库是否跟随新主库，如果未指定则不变 上述命令可以手动切换集群主备，对于用户运维很有帮助。 注意: 切换过程可能失败，或者部分操作失败，请在切换后查看集群状态。 切换过程示例： 1. 最初 primary 节点是 node102 104 第 5 章 参考 集群同步状态： 2. 选择 node101 为新的 primary。在 node101 运行：repmgr standby switchover --siblings-follow NOTICE: executing switchover on node "node101" (ID: 1) NOTICE: local node "node101" (ID: 1) will be promoted to primary; current primary "node102" (ID: 2) will be demoted to standby NOTICE: stopping current primary node "node102" (ID: 2) NOTICE: issuing CHECKPOINT NOTICE: node (ID: 2) release the virtual ip 192.168.237.100/24 success DETAIL: executing server command "/home/kingbase/cluster/PROJ01/DBCL/kingbase/bin/sys_ctl '/home/kingbase/cluster/PROJ01/DBCL/kingbase/data' -D -l /home/kingbase/cluster/PROJ01/DBCL/kingbase/bin/logfile -W -m fast stop" INFO: checking for primary shutdown; 1 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 2 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 3 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 4 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 5 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 6 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 7 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 8 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 9 of 60 attempts ("shutdown_check_timeout") INFO: checking for primary shutdown; 10 of 60 attempts ("shutdown_check_timeout") NOTICE: current primary has been cleanly shut down at location 0/18000028 NOTICE: PING 192.168.237.100 (192.168.237.100) 56(84) bytes of data. --- 192.168.237.100 ping statistics --2 packets transmitted, 0 received, +1 errors, 100% packet loss, time 1000ms WARNING: ping host"192.168.237.100" failed DETAIL: average RTT value is not greater than zero NOTICE: new primary node (ID: 1) acquire the virtual ip 192.168.237.100/24 success NOTICE: promoting standby to primary DETAIL: promoting server "node101" (ID: 1) using sys_promote() NOTICE: waiting up to 60 seconds (parameter "promote_check_timeout") for promotion to complete NOTICE: STANDBY PROMOTE successful DETAIL: server "node101" (ID: 1) was successfully promoted to primary NOTICE: issuing CHECKPOINT INFO: local node 2 can attach to rejoin target node 1 DETAIL: local node's recovery point: 0/18000028; rejoin target node's fork point: 0/180000A0 105 第 5 章 参考 NOTICE: setting node 2's upstream to node 1 WARNING: unable to ping "host=192.168.237.102 user=esrep dbname=esrep port=54321 connect_timeout=3 keepalives=1 keepalives_idle=10 keepalives_interval=1 keepalives_count=3" DETAIL: PQping() returned "PQPING_NO_RESPONSE" NOTICE: begin to start server at 2020-10-01 15:23:16.183728 NOTICE: starting server using "/home/kingbase/cluster/PROJ01/DBCL/kingbase/bin/sys_ctl -t 90 -D '/home/kingbase/cluster/PROJ01/DBCL/kingbase/data' -w -l /home/kingbase/cluster/PROJ01/DBCL/kingbase/bin/logfile start" NOTICE: start server finish at 2020-10-01 15:23:16.299152 NOTICE: replication slot "repmgr_slot_1" deleted on node 2 WARNING: 1 inactive replication slots detected DETAIL: inactive replication slots: - repmgr_slot_3 (physical) HINT: these replication slots may need to be removed manually NOTICE: NODE REJOIN successful DETAIL: node 2 is now attached to node 1 NOTICE: executing STANDBY FOLLOW on 1 of 1 siblings INFO: STANDBY FOLLOW successfully executed on all reachable sibling nodes NOTICE: switchover was successful DETAIL: node "node101" is now primary and node "node102" is attached as standby NOTICE: STANDBY SWITCHOVER has completed successfully 以上为主备切换命令打印的所有日志，可总结出如下大致步骤： 1). 在 node102 运行 checkpoint 2). 从 node102 去除 VIP 3). 在 node102 运行 sys_ctl stop，关闭数据库 4). 确认 vip 及 102 数据库已停止 5). 在 node101 启动 VIP，并运行 promote 命令，将 node101 数据库提升为 primary 6). 启动 node102 数据库 7). 在 node103 运行 repmgr standby follow 3. 切换结果验证 106 第 5 章 参考 5.6.5 备库跟随新主库（standby follow） 命令行命令： # 在存活的备数据库节点执行 repmgr standby follow [--upstream-node-id $NODE_ID] 参数说明： • 如果未指定--upstream-node-id，当前备节点会自动寻找当前主库，然后跟随主库——之后本节点会作为备库和 主库进行同步； • 如果指定了--upstream-node-id $NODE_ID，当前备节点会跟随 NODE_ID 节点，该节点可以是一个备库； 5.6.6 故障节点恢复为备库（node rejoin） 命令行命令： # 在故障的数据库节点执行 repmgr node rejoin -h ${主库 IP} -d esrep -U esrep -p ${主库 port} [--force-rewind] [--no-check-wal] # 可以执行简化后的命令 kbha -A rejoin -h ${主库 IP} 参数说明： • --force-rewind，当故障数据库和当前主库数据分歧后，需要指定此参数使用 sys_rewind 使得故障数据库和新主 库保持数据一致； • --no-check-wal，一般情况下不允许时间线高的数据库恢复为时间线低的主库的备库，此选项可以忽略时间线和 lsn 检查，必须和--force-rewind 一起使用； 使用示例： 1. Node101 由于数据库宕机，primary 切换到 node102 2. 执行命令将原主库 node101 重新加入集群 [kingbase@nn01 archive]$ repmgr node rejoin -h 192.168.237.102 -U esrep -d esrep WARNING: the item in /home/kingbase/.kbpass is not end in the right way INFO: local node 1 can attach to rejoin target node 2 107 第 5 章 参考 DETAIL: local node's recovery point: 0/4B000028; rejoin target node's fork point: 0/4B0000A0 NOTICE: setting node 1's upstream to node 2 WARNING: unable to ping "host=192.168.237.101 user=esrep dbname=esrep port=54321 connect_timeout=3 keepalives=1 keepalives_idle=10 keepalives_interval=1 keepalives_count=3" DETAIL: PQping() returned "PQPING_NO_RESPONSE" NOTICE: begin to start server at 2020-10-02 15:02:27.685836 NOTICE: starting server using "/home/kingbase/cluster/PROJ01/DBCL/kingbase/bin/sys_ctl -t 90 -D '/home/kingbase/cluster/PROJ01/DBCL/kingbase/data' -w -l /home/kingbase/cluster/PROJ01/DBCL/kingbase/bin/logfile start" NOTICE: start server finish at 2020-10-02 15:02:27.792657 NOTICE: replication slot "repmgr_slot_2" deleted on node 1 WARNING: 1 inactive replication slots detected DETAIL: inactive replication slots: - repmgr_slot_3 (physical) HINT: these replication slots may need to be removed manually NOTICE: NODE REJOIN successful DETAIL: node 1 is now attached to node 2 3. 确认集群状态 注意: 以上的例子 node101 在宕机后、rejoin 之前，并没有启动，也就是 node101 数据与 primary 并没有出现 di- verged。但如果 node101 宕机后曾经启动过，甚至修改了数据，这时 node101 重新加入时，就必须指定--force-rewind 选项。 5.6.7 克隆/重做备库（standby clone） 命令行命令： # 在备库上执行，从主库克隆数据目录到备库 repmgr standby clone -h ${主库 IP} -d esrep -U esrep -p ${主库 port} [--force] [--fast-checkpoint] 参数说明： • --force，如果本地存在数据目录且目录非空，使用此参数将覆盖该目录，否则将报错退出； 此命令调用 sys_basebackup 从主库克隆数据目录在备库，一般只在集群部署阶段、集群扩容节点阶段使用。如 果是运维过程处理问题，一般用于重建备库——某些故障数据库无法使用 node rejoin 恢复时，需要重建备库。 108 第 5 章 参考 • --fast-checkpoint，在主库上执行快速检查点。 未指定此参数，克隆动作会在主库上执行一个普通检查点，如果主库上一次检查点完成不久，本次普通检查点刷 新脏页到磁盘时会主动延迟，整个执行耗费时间会比快速检查点要更长。快速检查点则能够以最快速度完成。 重建备库示例： 1. 在主库查看集群现状 可以看到 node103 节点是异常，需要重新加入 2. 运行 repmgr node rejoin 报错 这是由于 node103 的 timeline 比 primary 要大，不能 rewind （此场景，除了重建备库外，还可以使用 node rejoin --no-check-wal 进行恢复） 3. 在主库执行命令 repmgr service pause 暂停集群自动恢复功能 4. 在备库删除 $data_directory（repmgr.conf 中的参数）目录下的所有文件，运行 repmgr standby clone [kingbase@nn03 data]$ repmgr standby clone -h 192.168.237.102 -U esrep -d esrep --fast-checkpoint NOTICE: destination directory "/home/kingbase/cluster/PROJ01/DBCL/kingbase/data" provided INFO: connecting to source node DETAIL: connection string is: host=192.168.237.102 user=esrep dbname=esrep DETAIL: current installation size is 411 MB NOTICE: checking for available walsenders on the source node (2 required) NOTICE: checking replication connections can be made to the source server (2 required) WARNING: the item in /home/kingbase/.kbpass is not end in the right way WARNING: the item in /home/kingbase/.kbpass is not end in the right way INFO: checking and correcting permissions on existing directory "/home/kingbase/cluster/PROJ01/DBCL/kingbase/data" NOTICE: starting backup (using sys_basebackup)... INFO: executing: /home/kingbase/cluster/PROJ01/DBCL/kingbase/bin/sys_basebackup -l "repmgr base backup" -D /home/kingbase/ cluster/PROJ01/DBCL/kingbase/data -h 192.168.237.102 -p 54321 -U esrep -c fast -X stream -S repmgr_slot_3 NOTICE: standby clone (using sys_basebackup) complete NOTICE: you can now start your Kingbase server HINT: for example: sys_ctl -D /home/kingbase/cluster/PROJ01/DBCL/kingbase/data start HINT: after starting the server, you need to re-register this standby with "repmgr standby register -force" to update the existing node record 109 第 5 章 参考 5. 在备库启动 node103 数据库，执行 repmgr standby register -F 注册为备库 6. 执行命令 repmgr service unpause 取消暂停 7. 确认集群状态 5.6.8 手动加载/卸载 VIP 命令行命令： # 需要有 root 权限，或者对应二进制权限大于 4755 # 加载 virtual_ip（在 repmgr.conf 中的参数） kbha -A loadvip kbha -A arping # 卸载 virtual_ip（在 repmgr.conf 中的参数） kbha -A unloadvip 说明： • 加载 VIP，必须完整执行以上两条命令，其他节点才能正常访问此节点的 VIP 在调用 sys_monitor.sh start 启动集群时，正常会在 primary 节点上启动 VIP。而如果 primary 异常，比如多个 primary，则需要人为确认 primary 节点，再手动加载 VIP。可以通过命令 kbha -A loadvip && kbha -A arping 在 primary 手动加 VIP。 使用示例： 110 第 5 章 参考 5.6.9 手动新增/删除节点 节点的新增与删除操作强烈建议通过部署工具（deploy）进行。在集群部署完成后，务必保证部署工具所在目录 的数据完整，不要轻易删除该目录数据，避免后续维护工作麻烦。 命令行通过一键脚本新增或删除节点的过程请参考：《金仓数据守护集群和读写分离集群使用手册》在线扩缩容 章节。 5.6.10 集群节点修改 sshd/sys_securecmdd 端口 集群依赖 sshd 端口或 sys_securecmdd（老版本为 es_server）端口，由 repmgr.conf 配置文件中的 use_scmd （老版本为 use_es_server）控制，为 on 表示使用 sys_securecmdd，为 off 表示使用 sshd。 sshd 进程默认运行在 22 端口，在使用 deploy 工具部署集群时，对应的端口必须与 sshd 运行端口一致，端口信 息在配置完成后，也会写入 repmgr.conf 文件。如果后续需要修改 sshd 运行端口，需同时修改 repmgr.conf 配置。 集群修改 sshd 端口步骤（以下步骤，每个节点都需要执行一次）： #1. 修改/etc/ssh/sshd_config 文件，修改 Port 参数为指定端口 Port 22 #2. 重启 sshd 服务 systemctl restart sshd #3. 修改 ${集群}/etc/repmgr.conf 文件，修改参数 111 第 5 章 参考 # 参数名称分多个版本，按最新版本-> 老版本，参数名称为： # scmd_options es_options ssh_options scmd_options='-q -o ConnectTimeout=10 -o StrictHostKeyChecking=no -o ServerAliveInterval=2 -o ServerAliveCountMax=5 -p 22' #4. 杀掉 kbha 和 repmgrd 进程，等待重启 kill -9 `pidof kbha repmgrd` #5. 查看集群状态（关注守护进程 repmgrd 是否为 running） repmgr service status 集群修改 sys_securecmdd 端口步骤（以下步骤，每个节点都需要执行一次）： #1. 修改/etc/.kes/securecmdd_config 文件，修改 Port 参数为指定端口 Port 8890 #2. 重启 sys_securecmdd 服务 systemctl restart securecmdd #ps: 如果为专用机，直接 ps -ef 查询 sys_securecmdd 进程并 kill，等待其重启 #3. 修改 ${集群}/etc/repmgr.conf 文件，修改参数 # 参数名称分多个版本，按最新版本-> 老版本，参数名称为： # scmd_options es_options ssh_options scmd_options='-q -o ConnectTimeout=10 -o StrictHostKeyChecking=no -o ServerAliveInterval=2 -o ServerAliveCountMax=5 -p 8890' #4. 杀掉 kbha 和 repmgrd 进程，等待重启 kill -9 `pidof kbha repmgrd` #5. 查看集群状态（关注守护进程 repmgrd 是否为 running） repmgr service status 5.6.11 集群用户密码修改 集群在部署过程中，主要涉及两个数据库用户： • system，超级用户，默认密码 12345678ab，初始化数据库时使用的默认用户 • esrep，超级用户，默认密码 Kingbaseha110，集群部署过程中创建的用户，专门用于集群 注意: 以上默认密码为最新版本的默认密码，老版本可能有所不同。 而集群过程中，会将数据库用户密码配置在多个文件中，用作不同的用途： 112 第 5 章 参考 • ~/.encpwd，数据库免密文件，保存 system 和 esrep 用户的密码，集群管理软件或其他本节点的应用连接数据 库时，默认使用此文件中的密码 • ${集群}/etc/all_nodes_tools.conf，监控配置文件，保存 system 用户的密码，kingbase_exporter 使用此文件 中的密码来连接本地数据库，监控数据库信息并提供给监控工具 注意: 以上文件集群每个节点都有一份，所有节点的文件内容都相同。 在修改以上数据库用户（system 或 esrep）的过程中，请使用提供的一键脚本来修改密码，一键脚本会同步修改 以上配置文件。否则，如果单独使用 SQL 自行修改 system 或 esrep 用户密码，将导致集群功能或监控工具出现未知 错误。 注意: 非 system 和 esrep 用户，可以随意修改密码。 一键脚本修改密码的具体步骤请参考：《金仓数据守护集群和读写分离集群使用手册》一键修改密码章节。 5.6.12 查看集群事件 命令行命令： # 在存活的数据库节点执行（当前数据库故障则无法查看） repmgr cluster event 5.7 常用的集群诊断工具 5.7.1 一键检查数据库状态工具 请参见《一键检查数据库状态工具》。 5.7.2 日志收集分析工具 请参见《日志收集分析工具》。 5.8 软件包安装及升级管理 请参见《KinbaseES 版本升级最佳实践》。 113 版权声明 版权声明 北京人大金仓信息技术股份有限公司（简称：人大金仓）版权所有，并保留对本手册及本声明的一切权利。 未得到人大金仓的书面许可，任何人不得以任何方式或形式对本手册内的任何部分进行复制、摘录、备份、修 改、传播、翻译成其他语言、将其全部或部分用于商业用途。 免责声明 本手册内容依据现有信息制作，由于产品版本升级或其他原因，其内容有可能变更。人大金仓保留在没有任何通 知或者提示的情况下对手册内容进行修改的权利。 本手册仅作为使用指导，人大金仓在编写本手册时已尽力保证其内容准确可靠，但并不确保手册内容完全没有错 误或遗漏，本手册中的所有信息也不构成任何明示或暗示的担保。 技术支持 • 人大金仓官方网站：http://www.kingbase.com.cn/ • 人大金仓文档中心：http://help.kingbase.com.cn/ • 全国服务热线：400-601-1188 • 人大金仓技术支持与反馈信箱：support@kingbase.com.cn 114 服务周期承诺 服务周期承诺 由于市场需求在不断变化，技术创新和发展的进程不断加剧，产品的版本更迭不可避免。人大金仓对于产品版本 生命周期的有效管理，有助于您提前规划项目，更好地从产品服务终止上过渡。 表 1: KingbaseES 产品生命周期里程碑 关键里程碑点 定义 产品发布日期 产品正式发布版本，即 GA（general availability）版本的发布日期。 停止销售日期 正式停止销售的日期，版本停止接受订单日。该日之后，产品将不再销售。 停止功能升级日期 在该日期之后，不再提供新特性和新硬件支持。但依旧提供错误修复、安全修复、功 能维护等服务。 停止功能维护日期 在该日期之后，不再维护功能，修复问题。但依旧提供安全修复等服务 停止安全维护日期 在该日期之后，不再发布补丁版本修复中高风险漏洞，仅提供有限的支持。 产品服务终止日期 停止提供产品服务和支持的日期。包括软件维护版本，缺陷修复，以及针对该产品的 所有服务支持（包括服务热线和远程/现场支持）。 服务周期策略 金仓数据库管理系统 KingbaseES 产品确保以下的服务周期： 1）产品自发布之日起至产品停止功能升级（包含新特性、新硬件支持）之日不少于 5 年。 2）产品停止功能升级之日起至产品停止功能维护（主要包括问题修复）之日不少于 4 年。 3）产品功能维护停止之日起至产品停止安全维护（包括中高风险漏洞修复）之日不少于 2 年。 服务终止策略 金仓数据库管理系统 KingbaseES 产品确保在销售后，至少提供 6 年的服务支持。 注意: 人大金仓将会综合各方因素来确定产品服务终止日期。并将在实际产品服务终止日期之前至少 90 天，通过公 115 服务周期承诺 开方式宣布产品服务终止日期。 116