尧图网站建设 
作为一个 DBA我每天到公司的第一件事不是先泡咖啡而是打开终端按部就班地完成一套巡检动作。这套流程我已经坚持了很久它帮我在故障发生前拦截过多次潜在风险。一、每日巡检的整体思路日常运维不是等出了问题再去救火而是通过固定化的检查提前发现苗头。每天的工作分成六个模块集群和节点状态数据库连接与负载慢 SQL 与锁等待存储空间与日志备份与复制状态参数与异常事件下面逐一说明具体操作和命令。二、集群与节点健康检查GBase 8c 采用的是分布式架构部署包含多个 Coordinator协调节点和 Datanode数据节点。我第一件事就是确认所有节点都在线。1. 查看集群状态使用 gha_ctl 工具查看集群整体状态gha_ctl monitor all -l dcslist输出中会列出每个节点的角色、主机名、端口和状态。正常情况下所有节点状态应为Normal或Running。如果有Down或Unstable需要立即排查。2. 检查节点心跳与资源使用登录每个节点快速看一下 CPU、内存、磁盘 I/Otop -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. 查询最近一段时间的慢 SQLGBase 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_basebackup或gs_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 21 echo --- Active Sessions --- $LOG_FILE gsql -d postgres -c SELECT count(*) FROM pg_stat_activity; $LOG_FILE 21 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 21 echo --- Disk Usage --- $LOG_FILE df -h data目录 $LOG_FILE 21 echo --- Replication Lag --- $LOG_FILE gsql -d postgres -c SELECT application_name, client_addr, state, replay_lag FROM pg_stat_replication; $LOG_FILE 21 echo --- Recent Errors --- $LOG_FILE grep -E ERROR|FATAL|PANIC 日志目录/pg_log/*.log | tail -20 $LOG_FILE 21 echo End $LOG_FILE配合crontab每天上班前自动执行我到公司只需要打开日志文件快速浏览即可。九、总结以上是我每天对 GBase 8c 集群的例行维护操作。看起来内容不少但熟练之后整个过程不会超过 15 分钟。关键在于坚持和标准化一旦形成习惯就能在问题扩大前及时处理。当然业务场景不同大家可以根据实际情况增删检查项。希望这份每日清单能对你的日常工作有所帮助。如果还有哪些值得每天关注的点欢迎在社区留言交流。 GBase 8c 日常运维例行维护实践——来自一位DBA的每日工作清单
作为一个 DBA我每天到公司的第一件事不是先泡咖啡而是打开终端按部就班地完成一套巡检动作。这套流程我已经坚持了很久它帮我在故障发生前拦截过多次潜在风险。一、每日巡检的整体思路日常运维不是等出了问题再去救火而是通过固定化的检查提前发现苗头。每天的工作分成六个模块集群和节点状态数据库连接与负载慢 SQL 与锁等待存储空间与日志备份与复制状态参数与异常事件下面逐一说明具体操作和命令。二、集群与节点健康检查GBase 8c 采用的是分布式架构部署包含多个 Coordinator协调节点和 Datanode数据节点。我第一件事就是确认所有节点都在线。1. 查看集群状态使用 gha_ctl 工具查看集群整体状态gha_ctl monitor all -l dcslist输出中会列出每个节点的角色、主机名、端口和状态。正常情况下所有节点状态应为Normal或Running。如果有Down或Unstable需要立即排查。2. 检查节点心跳与资源使用登录每个节点快速看一下 CPU、内存、磁盘 I/Otop -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. 查询最近一段时间的慢 SQLGBase 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_basebackup或gs_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 21 echo --- Active Sessions --- $LOG_FILE gsql -d postgres -c SELECT count(*) FROM pg_stat_activity; $LOG_FILE 21 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 21 echo --- Disk Usage --- $LOG_FILE df -h data目录 $LOG_FILE 21 echo --- Replication Lag --- $LOG_FILE gsql -d postgres -c SELECT application_name, client_addr, state, replay_lag FROM pg_stat_replication; $LOG_FILE 21 echo --- Recent Errors --- $LOG_FILE grep -E ERROR|FATAL|PANIC 日志目录/pg_log/*.log | tail -20 $LOG_FILE 21 echo End $LOG_FILE配合crontab每天上班前自动执行我到公司只需要打开日志文件快速浏览即可。九、总结以上是我每天对 GBase 8c 集群的例行维护操作。看起来内容不少但熟练之后整个过程不会超过 15 分钟。关键在于坚持和标准化一旦形成习惯就能在问题扩大前及时处理。当然业务场景不同大家可以根据实际情况增删检查项。希望这份每日清单能对你的日常工作有所帮助。如果还有哪些值得每天关注的点欢迎在社区留言交流。