当前位置: 首页 > news >正文

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 分钟。关键在于坚持和标准化,一旦形成习惯,就能在问题扩大前及时处理。

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

http://www.cnnetsun.cn/news/4361835.html

相关文章:

  • Git提交前到底该做什么?一套避免代码丢失和冲突的安全工作流
  • YOLO与多模态AI融合的智慧交通监测预警系统实践
  • 具身AI三耦合框架:世界模型如何攻克环境偏移与高交互成本
  • AI代理交易系统开发指南:从架构设计到安全实践
  • 从模板管理到Python自动化:打造高效PPT模板库
  • MR30系列分布式IO在汽车轮毂产线的应用
  • 突破零停机演进:Linux 内核 Live Update Orchestrator (LUO) 架构设计与热升级演进
  • IP68与IP69K防水等级区别:测试条件、应用场景与工程选型指南
  • mpx小程序跨端框架入门:从环境准备到多端构建实战
  • Shell脚本实战:从变量循环到三剑客,搞定Linux自动化运维
  • 面齿轮建模全流程:从Matlab齿面计算到TCA验证
  • 神经元修复:从生物大脑到人工神经网络的工程启示
  • 游戏卡池系统后端设计与实现:概率算法、保底机制与配置实战
  • HarmonyOS 应用开发之多语言国际化:zh_CN/en_US 限定词与 string.json 资源体系详解
  • HoRain云--CSS 属性 选择器
  • 南京矢量数据包全解析:SHP格式处理与坐标系转换实战
  • 生产计划管理有效方法揭秘:如何提升企业运营效率
  • ZYNQ双项目实战:FFT频谱分析与打地鼠游戏开发全流程复盘
  • 用Claude Code Skill实现ASO自动化:从关键词调研到文案生成
  • AlphaGo Zero源码深度解析:从策略网络到自我对弈机制
  • UG871设计文件实战:FPGA高层次综合HLS入门与优化指南
  • 把 ABAP Unit 覆盖率变成发布门禁,生产级自定义 ATC 检查的完整实现
  • 今日老黄历×周易姤卦×12星座运势排行榜
  • 让AI学会“看人下菜碟“:CLEAR解决大模型安全与好用之间的两难
  • 基于ReasonixGUI的DeepSeek Harness客户端:从思路到落地
  • Flask+Vue医院预约挂号系统实战:核心架构与源码解析
  • Excel批量转换数字符号:从基础公式到VBA宏的完整指南
  • 运放电路失真排查指南:从削波、交越失真到自激振荡
  • 超声波焊接塑胶件双工位气密检测:提效原理与产线落地指南
  • AI智能体记忆系统脆弱性分析:从灾难性遗忘到检索失效的工程加固