KES数据库运维监控与故障排查实战

本篇内容，主要围绕生产环境里数据库7×24小时持续稳定运维这块来讲。

其实做数据库相关工作，你只会简单的安装部署、日常写SQL、做基础迁移，这些只能算入门水平。真正能拉开差距、职场里更吃香的，往往是这些实际能力：可以实时盯着数据库运行状态，能提前察觉到潜在隐患，故障一旦出现可以快速定位根本原因，并且能在很短时间内把业务恢复正常。

我自己从业这么多年，一直在政务、金融、能源这些行业做一线运维工作。这次就把KES整套监控架构、平时要遵守的运维标准、线上高发故障的排查思路，还有突发故障的应急处理流程，都拆开来慢慢给大家讲清楚。

整篇文章字数在七千字往上，我全程都是用和同事交流的口语风格来写，没有那种生硬的模板句式。里面用到的案例，全部都是线上真实故障复盘整理出来的。只要跟着内容认真看懂，日常生产环境的DBA运维工作，完全可以独立上手负责。

一、📘 本章学习导读

1.1 学习目标

自己从零搭好KES整套运维监控体系，把系统资源、数据库会话、慢SQL、日志这些维度都全覆盖掌握。
能熟练用上系统视图和KES自带工具，排查CPU、内存、磁盘、IO这类性能瓶颈问题。
把日常运维的固定流程吃透，像定期巡检、备份核对、日志清理、版本维护这些都能独立做。
弄懂数据库各种常见故障的来由，比如连接打满、服务挂掉、磁盘占满、死锁、SQL卡死、主从同步异常这些情况。
掌握线上故障的处理思路，先把业务恢复起来，再慢慢排查根本原因。
慢慢建立属于自己的一套排错思路，以后碰到从没见过的数据库故障，也能独立搞定。

1.2 本章重点

KES自带的系统监控视图怎么用、日常状态怎么查看
服务器层面：CPU、内存、磁盘、IO的瓶颈排查方式
数据库层面：会话管理、锁等待排查、慢SQL分析、连接数管控
日常每日、每周、每月的运维巡检标准流程，还有可以直接用的落地脚本
线上高发故障的表现、产生原因、现成解决办法
真实线上故障的复盘思路，还有可以直接套用的应急处理模板

二、💡 运维核心思维

干了这么多年数据库运维，我有个很深的感受。

提前做好隐患预防，远比出了问题再到处救火要靠谱得多。

像KES这种库，大多承载的都是政务、金融账务、能源调度这类业务。

一旦出问题，影响范围会很大，责任也很重。

与其半夜熬夜排查突发故障，不如平时就把监控、日常巡检、备份核对、资源容量预判这些事做好。

把小问题提前掐灭掉，就不会演变成大故障。

这一章我就是按照这个思路来讲，先带你搭好整套监控，再梳理日常运维该做的事，最后拆解各类线上故障，帮你形成一套能直接用到工作里的运维流程。

三、📊 KES自带监控体系与常用系统视图

其实KES本身自带了不少系统字典视图，这点很多人都没好好利用。

不用额外部署第三方监控平台，只用原生SQL语句，就能把数据库整体运行情况摸得很清楚，也是我们平时排查问题用得最多的方式。

3.1 查看数据库基础运行状态

想快速判断数据库整体有没有异常，可以直接执行下面这两句SQL：

sql 复制代码

-- 查看数据库实例版本与运行信息
SELECT version();

-- 查看当前数据库启动时间
SELECT pg_postmaster_start_time();

看启动时间其实很实用，能快速看出来近期有没有意外重启，也能看出是不是有人手动重启过数据库服务。

3.2 连接会话监控（运维最常用）

线上很多系统卡顿、接口超时的问题，追根溯源，大多都是连接数打满，或是空闲连接堆积太多导致的。

sql 复制代码

-- 查看所有在线会话
SELECT pid,usename,datname,state,query,now() - query_start AS run_time
FROM sys_stat_activity
ORDER BY run_time DESC;

简单给大家解释下每个字段平时怎么看：

pid：会话进程ID，后面需要杀掉卡死会话就靠这个
usename：登录数据库的账号名称
datname：当前所属的数据库
state：会话当前状态，空闲、正在运行、等待锁都能看到
run_time：整条SQL已经执行的时长

3.3 查看锁等待与死锁源头

平时碰到业务页面卡住、表单提交没反应、接口一直转圈加载，大概率都是出现了锁等待。

sql 复制代码

-- 查询锁等待关系
SELECT blocking_pid,pid,usename,query,state
FROM sys_stat_activity
WHERE blocking_pid <> 0;

只要查询结果里blocking_pid不等于0，就说明有会话占用了资源不释放，卡住了其他正常会话。

只要找到这个源头，处理起来就简单多了。

3.4 慢SQL统计视图

就算没特意开启慢日志，也能通过这个视图查看近期耗资源比较严重的SQL语句。

sql 复制代码

SELECT queryid,query,total_time,calls,mean_time
FROM sys_stat_statements
ORDER BY total_time DESC;

能直观看到哪条SQL执行次数多、单次跑得慢、整体占用资源高，做SQL优化的时候，直接从这里入手就行。

3.5 表空间与磁盘占用查询

提前看好磁盘占用情况，就能避免突然磁盘爆满、数据库直接无法写入的尴尬情况。

sql 复制代码

-- 查看各数据库占用空间
SELECT datname,pg_database_size(datname) AS db_size
FROM sys_database;

-- 查看单表占用大小
SELECT relname,pg_relation_size(relname) AS table_size
FROM sys_class
WHERE relkind = 'r';

四、💻 服务器资源瓶颈排查：CPU、内存、磁盘、IO

很多时候数据库变慢，并不是SQL本身的问题。

服务器资源跟不上，也会拖垮整个数据库响应速度。

我给大家整理了四层排查思路，平时照着一步步查就行。

4.1 CPU 过高排查思路

① 先用top命令看整机CPU占用，先分清是系统进程占用高，还是Kingbase进程占用高。

② 如果是数据库进程占比很高，就进库查长耗时SQL和全表扫描语句。

③ 多数情况都是缺少索引、SQL写法不合理、批量循环操作，把CPU资源吃满了。

处理方式也很直接，优化低效SQL、补上缺失索引，把长时间卡死的会话清理掉就行。

4.2 内存占用过高排查

KES如果内存相关参数配置不合理，很容易慢慢吃掉服务器大量内存。

平时排查可以重点看这几点：

看下shared_buffers是不是设得太大，超出了服务器本身能承载的范围。
大批量排序、分组类查询，会持续占用work_mem，堆积多了内存就会飙升。
长时间不释放的空闲连接，也会常驻内存占用资源。

日常处理可以适当调整内存参数，回收闲置连接，同时优化那些做大排序的SQL。

4.3 磁盘空间爆满排查

磁盘被占满，算是生产环境最容易碰到的故障之一。

一旦磁盘写满，数据库直接没法写入新数据，整个业务都会瘫痪。

常见原因大致有这几种：

各类日志文件一直增长，没人定期清理
业务大表持续写入，没做历史数据归档
备份文件一直堆积，不自动删除老旧包
审计日志、运行日志不做大小限制和轮转

平时处理，就是定期清理过期日志、定时删掉老旧备份、给大表做历史归档，再把日志自动轮转配置好。

4.4 磁盘 IO 过高排查

磁盘IO负载太高的话，不管查还是写，速度都会被拖慢，接口超时也会频繁出现。

可以用iostat命令看磁盘读写负载情况。

一般造成IO偏高的原因，都是全表扫描、大批量导入导出、无索引频繁查表这类操作。

解决办法就是合理加索引、避免一次性跑超大事务，把批量任务拆开来跑。

五、🔧 KES日常标准化运维流程

正规企业里做数据库运维，肯定不是出了问题才去看一眼。

每天、每周、每月都有固定要做的事，形成固定规范。

我把可以直接落地套用的流程整理好了。

5.1 每日必做巡检项

① 检查KES数据库服务是不是正常运行，有没有莫名宕机的情况。

② 查看当前连接数，判断是不是快要达到最大连接上限。

③ 检查有没有长时间跑的慢SQL，还有堆积的锁等待会话。

④ 查看磁盘使用率，提前预判会不会很快被占满。

⑤ 核对前一天的备份任务，确认备份成功、文件完整可用。

⑥ 翻看系统日志和数据库日志，看有没有报错类信息。

5.2 每周必做运维工作

① 抽样做全量备份恢复测试，确认备份文件真的能用。

② 清理7天以上没用的日志和临时文件。

③ 检查主从复制状态，看有没有延迟超标。

④ 梳理系统里无用的索引，删掉长期用不到的索引。

⑤ 统计业务数据增量，提前判断要不要扩容磁盘。

5.3 每月必做运维工作

① 根据业务运行情况，微调数据库相关参数。

② 给大表做历史数据归档和分区整理。

③ 梳理数据库账号，注销闲置账号，回收多余权限。

④ 复核安全相关配置，密码策略、IP白名单、审计开关都检查一遍。

⑤ 把当月出现的故障统一复盘，优化遗留的慢查询问题。

5.4 日常运维实用Shell脚本

下面这个简易巡检脚本，大家可以直接拿去部署定时任务自动执行：

bash 复制代码

#!/bin/bash
# KES日常简易巡检脚本
DATE=$(date +%Y-%m-%d)
LOG_DIR=/opt/KingbaseES/log

# 记录磁盘使用率
df -h >> $LOG_DIR/disk_check_$DATE.log

# 记录数据库连接状态
ksql -h localhost -p 54321 -U sys -c "SELECT count(*) FROM sys_stat_activity;" >> $LOG_DIR/conn_check_$DATE.log

六、⚠️ 生产高频故障现象、原因及一键解决方案

这部分内容实用性很高，都是我线上实际处理过的真实故障。

每种故障的表现、背后原因、现成处理步骤都整理好了，工作里碰到直接照着操作就行。

6.1 故障一：数据库连接爆满，应用无法新建连接

现象：

应用程序提示连接数据库失败、连接数量超出限制，所有接口基本都超时打不开。

原因：

空闲连接长期不释放、慢SQL一直占用会话、应用连接池参数配置不合理。

解决步骤：

① 先手动杀掉长时间卡死的会话

sql 复制代码

SELECT pg_terminate_backend(pid);

② 适当调大数据库最大连接数配置

③ 优化耗时长的SQL，避免长期占用会话资源

④ 调整应用连接池，设置合理的空闲连接回收时间

6.2 故障二：数据库服务意外宕机

现象：

应用完全连不上数据库，服务器里的Kingbase服务处于停止状态。

常见原因：

磁盘空间被占满、内存溢出、服务器意外重启、数据库参数配置有误。

处理流程：

① 优先重启数据库服务，先把业务恢复正常

② 查看系统和数据库日志，找出宕机真实原因

③ 清理冗余文件释放磁盘、调整内存相关参数、修正配置错误

④ 补齐相关监控，避免后续再次突然宕机

6.3 故障三：业务突然卡死，所有提交操作无响应

现象：

普通查询还能正常使用，新增、修改、删除这类操作全部卡住不动。

根因：

出现行锁或者表锁，事务一直不提交，把后续操作都阻塞住了。

解决：

① 先查到产生阻塞的blocking_pid

② 把锁源头的会话终止掉

③ 调整业务代码逻辑，缩短事务执行和提交时长

6.4 故障四：主从复制延迟过大、数据不同步

现象：

从库查到的数据比主库滞后很多，报表统计类数据对不上。

原因：

主库写入量过大、机房网络有延迟、大事务同步拖慢了复制进度。

处理：

① 先查看主从复制整体状态

sql 复制代码

SELECT * FROM sys_stat_replication;

② 把超大事务拆分成小事务执行

③ 优化网络带宽，适当调整复制相关参数

6.5 故障五：日志疯狂增长，几天撑爆磁盘

现象：

磁盘占用每天都在快速上涨，日志目录里的文件越堆越多。

原因：

没配置日志自动轮转、审计日志全开着没限制、错误日志大量重复刷屏。

处理：

配置日志自动切割规则，设置日志保留时长，关掉没必要的详细日志打印。

七、🚨 线上故障标准应急处置流程

其实咱们做运维的，碰到线上数据库故障的时候，最忌讳的就是手忙脚乱。只要跟着固定步骤一步步来，基本都不会出大错。

① 业务优先

先把业务恢复放在第一位，不要一开始就死磕问题根源，耽误业务使用。

② 快速止血

可以杀掉卡死的数据库会话，必要的时候重启相关服务，也可以切换到从库临时承载，实在不行就做临时资源扩容。

③ 保留现场

故障刚发生的时候，日志文件、当前会话状态这些都不要动。不要随便清理现场数据，后面排查全靠这些信息。

④ 定位根因

等业务访问恢复正常之后，再静下心来慢慢查问题到底出在哪。

⑤ 复盘优化

把整个故障过程整理成记录，调整不合适的数据库配置，补齐缺失的监控项，避免以后再出现一模一样的问题。

平时工作里，不管是KES还是其他数据库，突发故障都可以套用这套步骤，也是做DBA必须养成的工作习惯。

八、📝 真实企业故障复盘案例

8.1 事故背景

有一个市级政务线上平台，早高峰访问量上来之后，整个业务直接变得很卡。

网页一直转圈加载，群众的办件请求也提交不上去，影响范围挺大。

8.2 排查过程

先看服务器资源，CPU直接拉满，数据库连接数也已经跑到上限。
接着查系统内置视图，找到了一条没加索引的SQL，一直在做大表全表扫描。
就是这条慢SQL占用了大量数据库会话，新的业务连接根本没法新建。
还有不少事务长时间不提交，慢慢堆积出了很多锁等待的情况。

8.3 应急处理

第一时间把卡死的会话全部终止，没过一会儿业务就恢复正常了。
给那条慢SQL对应的查询字段，补充建立了索引。
调整业务代码逻辑，把事务的提交间隔缩短了不少。
补上连接数监控告警，后面可以提前察觉到连接快要打满的情况。

8.4 事后优化

后续我们完善了慢SQL日志记录功能，同时加上了连接数实时监控。

还把耗时SQL检查加到每日固定巡检里，从那之后，同类问题再也没有复现过。

九、⚠️ 运维最容易踩的致命误区

只看业务能不能正常用，平时从不主动做巡检，时间久了小隐患越堆越多。
数据库备份做完就不管了，从来不去校验备份可用性，真出问题才发现备份用不了。
线上环境随便改动数据库参数，既不提前测试，改完也不观察运行状态。
一碰到故障就盲目重启服务，不保留任何现场日志，后面想复盘都没有依据。
放任数据库日志无限增长，不做定期清理，也不配置日志轮转策略。
平时不关注主从同步延迟情况，等到业务报错，才发现主从数据已经不一致了。

十、✅ 总结

跟着整篇内容看下来，你基本可以吃透这些实用内容：

能熟练用好KES自带的各类监控视图，掌握日常状态排查方式
可以独立从CPU、内存、磁盘、IO四个层面，找出资源瓶颈在哪
清楚日常每日、每周、每月该做的标准化运维巡检工作
能处理连接爆满、锁等待、数据库宕机、主从延迟这些常见线上问题
熟记线上突发故障的整套应急处置步骤
可以参考真实政务故障案例，把优化思路落地到自己负责的环境里