news 2026/9/2 0:07:02

GBase 8c 日常运维例行维护实践——来自一位DBA的每日工作清单

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
GBase 8c 日常运维例行维护实践——来自一位DBA的每日工作清单

作为一个 DBA,我每天到公司的第一件事,不是先泡咖啡,而是打开终端,按部就班地完成一套巡检动作。这套流程我已经坚持了很久,它帮我在故障发生前拦截过多次潜在风险。

一、每日巡检的整体思路

日常运维不是等出了问题再去救火,而是通过固定化的检查,提前发现苗头。每天的工作分成六个模块:

  1. 集群和节点状态
  2. 数据库连接与负载
  3. 慢 SQL 与锁等待
  4. 存储空间与日志
  5. 备份与复制状态
  6. 参数与异常事件

下面逐一说明具体操作和命令。

二、集群与节点健康检查

GBase 8c 采用的是分布式架构部署,包含多个 Coordinator(协调节点)和 Datanode(数据节点)。我第一件事就是确认所有节点都在线。

1. 查看集群状态

使用 gha_ctl 工具查看集群整体状态:

gha_ctl monitor all -l <dcslist>

输出中会列出每个节点的角色、主机名、端口和状态。正常情况下,所有节点状态应为NormalRunning。如果有DownUnstable,需要立即排查。

2. 检查节点心跳与资源使用

登录每个节点,快速看一下 CPU、内存、磁盘 I/O:

top -bn1 | head -20 free -g iostat -x 1 3

重点关注数据库进程(如gbased)的 CPU 使用率是否异常偏高、内存是否接近耗尽、磁盘 I/O 是否长时间 100%。

三、数据库连接与负载检查

数据库连接数直接反映业务压力,连接数过高可能引发资源争抢甚至拒绝服务。

1. 查看当前连接数

通过gsql登录任意协调节点,执行:

SELECT count(*) FROM pg_stat_activity;

也可以按数据库、用户、客户端地址分组统计:

SELECT datname, usename, client_addr, count(*) FROM pg_stat_activity GROUP BY datname, usename, client_addr ORDER BY count(*) DESC;

2. 检查是否接近连接上限

SHOW max_connections;

如果当前连接数长期超过max_connections的 80%,需要考虑扩容或优化应用连接池。

3. 关注空闲连接

大量空闲连接会白白占用资源:

SELECT pid, usename, client_addr, state, query_start FROM pg_stat_activity WHERE state = 'idle' ORDER BY query_start;

对于长时间空闲且无事务的连接,我会记录并反馈给开发,推动应用侧及时释放。

四、慢 SQL 与锁等待分析

这是每天的重头戏。慢 SQL 和锁等待会直接影响用户体验,甚至拖垮整个集群。

1. 查询最近一段时间的慢 SQL

GBase 8c 会将执行时间超过log_min_duration_statement的 SQL 记录到日志中。我习惯直接查看日志目录:

grep "duration:" pg_log/*.log | tail -100

也可以使用系统视图查看当前正在执行的长事务:

SELECT pid, usename, datname, state, now() - xact_start AS xact_duration, now() - query_start AS query_duration, query FROM pg_stat_activity WHERE state <> 'idle' AND (now() - query_start) > interval '5 seconds' ORDER BY query_duration DESC;

2. 检查锁等待

SELECT l.pid, l.locktype, l.mode, l.granted, a.usename, a.query, a.query_start FROM pg_locks l JOIN pg_stat_activity a ON l.pid = a.pid WHERE NOT l.granted;

如果发现未授权的锁长期存在,说明有锁等待甚至死锁风险。结合pg_blocking_pids()可以找出阻塞源头:

SELECT pid, pg_blocking_pids(pid) AS blocked_by, query FROM pg_stat_activity WHERE cardinality(pg_blocking_pids(pid)) > 0;

对于确认无用的阻塞会话,我会先与应用确认,再执行pg_terminate_backend(pid)终止。

五、存储空间与日志检查

磁盘写满是最常见的数据库故障之一,每天检查空间是必须的。

1. 数据库数据目录使用率

df -h <DATA目录>

确保使用率不超过 80%。如果接近阈值,需要清理归档日志、审计日志或扩容。

2. 审计日志和运行日志

du -sh <日志目录/audit> du -sh <日志目录/pg_log>

根据设置的保留策略,及时清理过期日志。如果开启了详细审计,日志增长速度会很快,要特别关注。

3. 表空间与表大小

定期(不一定每天)检查大表增长趋势:

SELECT schemaname, relname, pg_size_pretty(pg_total_relation_size(relid)) FROM pg_stat_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;

每天看一眼有没有异常膨胀的表,尤其是频繁更新但未及时 vacuum 的表。

六、备份与复制状态

数据安全是 DBA 的生命线,备份状态每天必查。

1. 检查最近备份是否成功

如果使用gs_basebackupgs_probackup,查看备份日志或备份目录:

ls -lt /backup/gbase8c/ | head -5

确认有当天或昨天的备份文件,且大小合理。

2. 检查主备复制状态

在协调节点和数据节点上都要看:

SELECT application_name, client_addr, state, sync_state, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;

replay_lag如果持续增长,说明备机延迟严重,需要排查网络或备机负载。

如果没有开启备机,至少确认集群中没有单点故障风险。

七、参数与异常事件

最后,我会快速扫一遍数据库日志中的异常信息。

1. 查看错误日志

grep -E "ERROR|FATAL|PANIC" <日志目录>/pg_log/*.log | tail -50

重点关注连接失败、认证失败、磁盘写入失败等错误。

2. 检查核心参数是否被意外修改

SHOW shared_buffers; SHOW work_mem; SHOW max_connections;

虽然参数一般不会自己变,但偶尔有误操作或自动化脚本改动的可能。

八、自动化脚本示例

为了提高效率,我把以上命令封装成一个简单的巡检脚本daily_check.sh,每天定时执行并把结果输出到文件或发送到企业微信。

#!/bin/bash # GBase 8c 每日巡检脚本 LOG_FILE="/tmp/gbase8c_daily_check_$(date +%F).log" echo "===== GBase 8c Daily Check $(date) =====" > $LOG_FILE echo "--- Cluster Status ---" >> $LOG_FILE gs_om -t status --all >> $LOG_FILE 2>&1 echo "--- Active Sessions ---" >> $LOG_FILE gsql -d postgres -c "SELECT count(*) FROM pg_stat_activity;" >> $LOG_FILE 2>&1 echo "--- Lock Waiting ---" >> $LOG_FILE gsql -d postgres -c "SELECT pid, mode, granted, query FROM pg_locks l JOIN pg_stat_activity a ON l.pid = a.pid WHERE NOT granted;" >> $LOG_FILE 2>&1 echo "--- Disk Usage ---" >> $LOG_FILE df -h <data目录> >> $LOG_FILE 2>&1 echo "--- Replication Lag ---" >> $LOG_FILE gsql -d postgres -c "SELECT application_name, client_addr, state, replay_lag FROM pg_stat_replication;" >> $LOG_FILE 2>&1 echo "--- Recent Errors ---" >> $LOG_FILE grep -E "ERROR|FATAL|PANIC" <日志目录>/pg_log/*.log | tail -20 >> $LOG_FILE 2>&1 echo "===== End =====" >> $LOG_FILE

配合crontab每天上班前自动执行,我到公司只需要打开日志文件快速浏览即可。

九、总结

以上是我每天对 GBase 8c 集群的例行维护操作。看起来内容不少,但熟练之后整个过程不会超过 15 分钟。关键在于坚持和标准化,一旦形成习惯,就能在问题扩大前及时处理。

当然,业务场景不同,大家可以根据实际情况增删检查项。希望这份每日清单能对你的日常工作有所帮助。如果还有哪些值得每天关注的点,欢迎在社区留言交流。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/1 23:59:15

Git提交前到底该做什么?一套避免代码丢失和冲突的安全工作流

Git提交前到底该做什么&#xff1f;一套避免代码丢失和冲突的安全工作流 很多人把 Git 当成“改完代码&#xff0c;git add .、git commit、git push”的三连工具。直到某一天&#xff1a;密钥进了仓库&#xff0c;别人的修改被覆盖&#xff0c;冲突文件被误删&#xff0c;或者…

作者头像 李华
网站建设 2026/9/1 23:56:05

YOLO与多模态AI融合的智慧交通监测预警系统实践

交通监控中心的大屏上&#xff0c;几十路视频画面同时滚动。过去&#xff0c;这个岗位主要靠人眼盯屏&#xff0c;发现异常后由值班员切换镜头、确认位置、再通知现场处置。这套流程本身没有问题&#xff0c;问题在于人的注意力无法长时间保持&#xff0c;尤其在夜间、雨天和多…

作者头像 李华
网站建设 2026/9/1 23:56:04

具身AI三耦合框架:世界模型如何攻克环境偏移与高交互成本

做具身AI项目&#xff0c;最让人头疼的往往不是网络结构选型&#xff0c;而是“策略在仿真环境里明明跑得很好&#xff0c;一迁移到真实机器人上就完全失灵”。你会在无数个夜晚反复确认同一个问题&#xff1a;代码没改&#xff0c;模型没动&#xff0c;为什么性能掉得这么厉害…

作者头像 李华
网站建设 2026/9/1 23:54:46

AI代理交易系统开发指南:从架构设计到安全实践

如果你是一名开发者&#xff0c;最近可能已经注意到一个趋势&#xff1a;越来越多的技术讨论开始从“AI能写代码”转向“AI能直接操作真实系统”。这不再是科幻想象&#xff0c;而是正在发生的现实。最近&#xff0c;全球最大的加密货币交易平台之一币安&#xff08;Binance&am…

作者头像 李华
网站建设 2026/9/1 23:54:31

从模板管理到Python自动化:打造高效PPT模板库

经常在职场里见到这样一类人&#xff1a;电脑里存了好几个“10000PPT模板合集”&#xff0c;网盘里还有十几个G的资料包&#xff0c;可真到要做汇报的时候&#xff0c;还是打开空白PPT从头开始。为什么&#xff1f;因为那一堆模板根本没有被真正管理起来&#xff0c;它们只是被…

作者头像 李华
网站建设 2026/9/1 23:52:40

MR30系列分布式IO在汽车轮毂产线的应用

新能源汽车产业高速发展&#xff0c;铝合金轮毂制造正向着高精度、高节拍、柔性化生产加速升级。轮毂智能产线具备物理跨度大、工位布局零散、设备类型繁杂的特点&#xff0c;且需要24小时不间断连续生产&#xff0c;对控制系统的稳定性、抗干扰能力、实时响应速度提出了严苛的…

作者头像 李华