保姆级教程：手把手教你监控人大金仓KingbaseES读写分离集群的健康状态（附排查脚本）
深度实战：KingbaseES读写分离集群健康监控全指南
在数据库运维领域，高可用集群的健康监控如同人体的定期体检，能够提前发现潜在问题，避免系统崩溃带来的业务中断。对于使用人大金仓KingbaseES的企业来说，读写分离集群的稳定运行直接关系到核心业务的连续性。本文将从一个资深DBA的视角，分享一套经过实战检验的监控方法论，涵盖从基础状态检查到高级预警策略的全套解决方案。
1. 集群健康监控的核心维度
1.1 节点存活状态检查
节点是集群的基本组成单元，其存活状态直接影响整个系统的可用性。通过以下命令可以快速获取集群拓扑：
repmgr cluster show --compact典型输出示例：
ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string ----+-------+---------+-----------+----------+----------+----------+----------+------------------ 1 | node1 | primary | running | | default | 100 | 5 | host=node1... 2 | node2 | standby | running | node1 | default | 90 | 5 | host=node2...关键监控指标：
- Status列：任何非"running"状态都需要立即报警
- Upstream关系：确保备节点正确指向主节点
- Timeline一致性：所有节点应在同一时间线
注意：执行此命令需要连接到任一存活节点，如果集群完全不可用，则需要直接登录服务器检查进程状态。
1.2 流复制状态深度分析
流复制是主备同步的核心机制，通过查询系统视图获取详细信息：
SELECT application_name, client_addr, state, sync_state, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes, EXTRACT(EPOCH FROM (now() - reply_time)) AS lag_seconds FROM sys_stat_replication;健康状态判断标准：
- state：必须为"streaming"
- sync_state：应与配置的同步模式匹配
- lag_bytes：业务高峰期不应超过100MB
- lag_seconds：建议报警阈值为60秒
对于关键业务系统，建议在监控系统中记录历史延迟趋势，便于容量规划。
2. 自动化监控脚本实现
2.1 基础检查脚本
以下是一个可直接使用的Bash检查脚本，返回值为0表示健康，非0表示异常：
#!/bin/bash # 配置部分 DB_USER="monitor_user" DB_NAME="postgres" PRIMARY_HOST="node1" REPLICATION_LAG_WARN=104857600 # 100MB REPLICATION_LAG_CRIT=524288000 # 500MB # 节点状态检查 NODE_STATUS=$(psql -h $PRIMARY_HOST -U $DB_USER -d $DB_NAME -tAc "SELECT status FROM repmgr.nodes WHERE name=iname;") if [ "$NODE_STATUS" != "running" ]; then echo "ERROR: Node status is $NODE_STATUS" exit 1 fi # 流复制延迟检查 LAG_BYTES=$(psql -h $PRIMARY_HOST -U $DB_USER -d $DB_NAME -tAc \ "SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM sys_stat_replication LIMIT 1;") if [ -z "$LAG_BYTES" ]; then echo "ERROR: No replication detected" exit 2 elif [ "$LAG_BYTES" -gt $REPLICATION_LAG_CRIT ]; then echo "CRITICAL: Replication lag $LAG_BYTES bytes" exit 3 elif [ "$LAG_BYTES" -gt $REPLICATION_LAG_WARN ]; then echo "WARNING: Replication lag $LAG_BYTES bytes" exit 4 fi echo "OK: Cluster is healthy" exit 02.2 进阶监控方案
对于企业级环境，建议采用Prometheus+Grafana的方案：
- 指标暴露：配置
kb_exporter暴露KingbaseES指标 - 告警规则示例：
groups: - name: kingbase.rules rules: - alert: HighReplicationLag expr: kb_replication_lag_bytes > 100000000 for: 5m labels: severity: warning annotations: summary: "High replication lag on {{ $labels.instance }}" description: "Replication lag is {{ $value }} bytes"- Grafana面板关键图表：
- 复制延迟趋势图
- 节点状态矩阵
- 事务处理速率对比
3. 常见故障场景与处理
3.1 主备切换异常
当手动执行切换失败时，可按以下流程处理：
- 检查原主节点是否真正停止：
ps -ef | grep "kingbase -D"- 强制清理旧主节点：
repmgr node rejoin --force-rewind -h <新主IP>- 验证数据一致性：
SELECT count(*) FROM pg_class WHERE relkind='r';3.2 复制槽堆积问题
复制槽不释放会导致WAL日志堆积，最终填满磁盘。检查命令：
SELECT slot_name, active, xmin, restart_lsn FROM sys_replication_slots;处理方案：
- 对于长期不活跃的slot，考虑手动删除
- 设置
max_slot_wal_keep_size参数限制保留量 - 监控
pg_wal目录大小
4. 性能优化建议
4.1 网络层优化
在高延迟网络环境下，调整以下参数：
# kingbase.conf max_wal_senders = 10 wal_keep_segments = 1024 synchronous_commit = remote_write4.2 存储层配置
使用SSD存储时推荐配置：
wal_compression = on full_page_writes = off synchronous_commit = off4.3 内存参数调优
根据服务器内存调整：
shared_buffers = 8GB work_mem = 16MB maintenance_work_mem = 1GB在实际生产环境中，我们曾遇到过一个典型案例：某金融系统在月初报表期间出现复制延迟飙升，通过分析发现是大量索引扫描导致备库回放变慢。最终通过调整vacuum_cost_delay参数和优化查询，将延迟控制在10秒以内。