GaussDB 运维实战：从连接监控到性能调优的日常巡检清单

1. 数据库连接监控：运维的第一道防线

每天早上打开电脑的第一件事，我总是习惯性地检查数据库连接情况。这就像医生查房时要先看病人的生命体征一样，连接状态直接反映了数据库的健康程度。在GaussDB中，我最常用的就是pg_stat_activity视图，它能显示所有活跃连接的关键信息。

最基础的查询命令是：

SELECT * FROM pg_stat_activity;

但实际工作中我更推荐使用这个增强版查询：

SELECT usename AS 用户名, client_addr AS 客户端IP, count(1) OVER(PARTITION BY usename, client_addr) AS 连接数, count(1) OVER() AS 总连接数, query AS 当前SQL, state AS 状态 FROM pg_stat_activity;

这个查询能一目了然地看到：

• 哪些用户建立了连接
• 每个客户端的连接数
• 当前执行的SQL语句
• 连接状态（active/idle等）

连接数突增是最常见的警报信号。上周我们就遇到一个典型case：某业务系统凌晨跑批时连接数突然从平时的50+飙升到300+，导致新连接无法建立。通过上述查询快速定位到是某个ETL作业没有正确关闭连接。解决方法也很简单：

-- 先确认异常连接 SELECT pid, usename, query_start, query FROM pg_stat_activity WHERE usename = 'etl_user' AND state = 'idle'; -- 然后批量清理 SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'etl_user' AND state = 'idle' AND current_timestamp - query_start > interval '1 hour';

对于连接监控，我总结了几条经验：

1. 建立基线数据：记录业务高峰时段的正常连接数范围
2. 设置关键指标告警：如单用户连接数超过20、总连接数超过max_connections的80%
3. 定期检查长时间空闲连接（超过30分钟）
4. 特别注意ETL和报表系统的连接管理

2. 集群健康检查：从宏观到微观的体检

确认集群状态是日常巡检的核心环节。GaussDB提供了gs_om工具来检查集群整体健康状况：

gs_om -t status

这个命令会返回集群的总体状态，重点关注两个字段：

• Cluster State：正常应为"Normal"
• Balanced：正常应为"Yes"

但作为资深DBA，我更喜欢用详细模式检查：

gs_om -t status --detail

这个命令会显示每个节点的详细状态，包括：

• 节点角色（Coordinator/Datanode）
• 节点状态（Primary/Standby）
• 同步状态
• 最后心跳时间

典型故障排查场景：

1. 当某个Datanode显示为"Down"状态时：

   • 先检查节点进程：ps -ef | grep gaussdb
   • 查看节点日志：cd $GAUSSLOG; grep -i error pg_log/*
   • 尝试重启节点：gs_om -t restart -D /path/to/data_dir

2. 当Balanced状态为"No"时：

   • 检查网络连通性：ping 节点IP
   • 验证复制状态：gs_ctl query -D /path/to/data_dir
   • 必要时重建备节点

3. 参数检查与调整：

-- 查看关键参数 SHOW max_connections; SHOW shared_buffers; SHOW work_mem; -- 动态调整参数 gs_guc reload -Z coordinator -N all -I all -c "work_mem=16MB"

3. 日志分析：数据库的"黑匣子"

日志是故障诊断的金矿。GaussDB的日志系统非常完善，主要包括：

• 运行日志：$GAUSSLOG/pg_log/
• 黑匣子日志：core dump文件
• CM集群管理日志：$GAUSSLOG/cm/

日常日志检查流程：

1. 首先定位日志目录：

echo $GAUSSLOG cd $GAUSSLOG/pg_log

2. 使用grep快速扫描错误：

# 查找过去24小时的错误日志 grep -i error `find . -mtime -1` # 查找特定错误码 grep "XX000" postgresql-2023-08-*.log

3. 分析长事务警告：

grep "duration:" postgresql-2023-08-*.log | awk -F 'duration:' '{print $2}' | sort -nr | head

黑匣子日志配置技巧：

# 限制core文件数量避免磁盘爆满 gs_guc set -Z datanode -N all -I all -c "bbox_dump_count=4" # 设置专用core文件目录 mkdir /corefiles chmod 750 /corefiles gs_guc set -Z datanode -N all -I all -c "bbox_dump_path='/corefiles'"

4. 空间与锁监控：预防性维护的关键

空间管理

空间不足是生产环境最常见的问题之一。我常用的空间检查命令：

-- 检查所有表空间 SELECT oid, spcname, pg_size_pretty(pg_tablespace_size(oid)) FROM pg_tablespace; -- 检查特定表大小 SELECT relname AS 表名, pg_size_pretty(pg_total_relation_size(relid)) AS 总大小, pg_size_pretty(pg_relation_size(relid)) AS 数据大小, pg_size_pretty(pg_indexes_size(relid)) AS 索引大小 FROM pg_stat_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;

空间优化建议：

1. 对大表定期执行VACUUM FULL（注意锁问题）
2. 对频繁更新的表设置合理的autovacuum参数
3. 考虑分区表管理历史数据
4. 监控WAL日志增长

锁监控

锁竞争会严重影响数据库性能。我的锁监控方案：

-- 查看当前锁等待 SELECT blocked_locks.pid AS blocked_pid, blocked_activity.usename AS blocked_user, blocking_locks.pid AS blocking_pid, blocking_activity.usename AS blocking_user, blocked_activity.query AS blocked_query, blocking_activity.query AS blocking_query FROM pg_catalog.pg_locks blocked_locks JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid AND blocking_locks.pid != blocked_locks.pid JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid WHERE NOT blocked_locks.GRANTED;

锁问题处理步骤：

1. 先确认阻塞关系
2. 尝试联系阻塞会话的用户
3. 必要时终止阻塞会话：

SELECT pg_terminate_backend(阻塞PID);

5. SQL性能调优：从应急到预防

性能问题80%来自不良SQL。我的SQL调优工具箱：

执行计划分析

-- 基础执行计划 EXPLAIN SELECT * FROM large_table WHERE create_date > '2023-01-01'; -- 带实际执行统计 EXPLAIN ANALYZE SELECT * FROM large_table WHERE create_date > '2023-01-01'; -- 详细性能分析 EXPLAIN PERFORMANCE SELECT * FROM large_table WHERE create_date > '2023-01-01';

执行计划解读要点：

1. 检查是否使用了合适的索引
2. 注意Seq Scan全表扫描
3. 关注预估行数和实际行数的差异
4. 警惕Nested Loop连接大表

统计信息维护

-- 检查统计信息时效 SELECT schemaname, relname, last_analyze, analyze_count FROM pg_stat_all_tables WHERE last_analyze < now() - interval '7 days' ORDER BY last_analyze; -- 收集统计信息 ANALYZE 关键表;

索引优化

-- 检查索引使用情况 SELECT schemaname, relname, indexrelname, idx_scan FROM pg_stat_all_indexes WHERE idx_scan < 100 -- 很少使用的索引 ORDER BY idx_scan, schemaname, relname; -- 检查重复索引 SELECT indrelid::regclass AS 表名, array_agg(indexrelid::regclass) AS 重复索引 FROM pg_index GROUP BY indrelid, indkey HAVING count(*) > 1;

6. 备份恢复：最后的安全网

备份是DBA的底线。GaussDB提供多种备份方式：

全量备份

# 磁盘备份 python GaussRoach.py -t backup \ --master-port 6000 \ --media-destination /backup/gaussdb \ --media-type Disk \ --metadata-destination /backup/metadata

单表备份

python GaussRoach.py -t backup \ --master-port 6000 \ --media-destination /backup/gaussdb \ --media-type Disk \ --agent-port 7000 \ --dbname mydb \ --tablename important_table \ --metadata-destination /backup/metadata

备份验证要点

1. 定期测试恢复流程
2. 监控备份文件大小变化
3. 检查备份日志是否有错误
4. 确保有足够的磁盘空间

7. 自动化巡检脚本实践

为了提高效率，我开发了一套自动化巡检脚本，主要功能包括：

1. 连接健康检查
2. 空间使用监控
3. 关键参数验证
4. 性能指标采集
5. 自动生成巡检报告

示例检查项：

#!/bin/bash # 连接数检查 CONN_COUNT=$(gsql -d postgres -U monitor -c "SELECT count(*) FROM pg_stat_activity;" -t | awk '{print $1}') # 空间检查 SPACE_USAGE=$(gsql -d postgres -U monitor -c "SELECT pg_size_pretty(pg_database_size('my_db'));" -t) # 生成报告 echo "GaussDB巡检报告 - $(date)" echo "========================" echo "1. 当前连接数: $CONN_COUNT" echo "2. 数据库大小: $SPACE_USAGE"

这套脚本配合cron定时任务，每天自动运行并邮件发送报告，大大提高了运维效率。