数据库运维不缺命令常见的问题是没有把关键动作固定下来。参数改了却没留记录备份任务一直显示成功却没做过恢复监控里只有当前 CPU 使用率。等故障发生再临时翻日志往往已经错过了最有价值的现场。本文内容重点放在日常管理中需要长期执行的事项不做参数手册式罗列。一、排查前先核对版本和环境开始排查前先看数据库版本。不同版本的参数名称、插件支持范围和兼容行为可能有差异其他环境里的配置不能直接照搬。SELECTversion();日常连接可以准备一条固定模板减少临时填写主机、端口和数据库名时出错的概率ksql-h192.168.10.20-p54321-Usystem-dprod连接后先确认当前实例和配置文件位置SELECTcurrent_database(),current_user;SHOWdata_directory;SHOWconfig_file;SHOWhba_file;SHOWlisten_addresses;SHOWport;SHOWssl;生产环境还要明确参数、安全策略和审计分别由谁负责。业务账号不要兼任管理账号应用也不应长期使用管理员账号连接数据库。这类问题平时不明显一旦账号泄露或发生误操作影响范围会很大。每次变更至少记录以下内容变更原因和负责人修改前后的参数值是否需要 reload 或重启回退方法验证结果配置文件、部署脚本和巡检脚本建议纳入版本管理。密码、密钥和证书不要提交到代码仓库。二、判断参数是否生效要看实例当前值KingbaseES 的参数可能来自kingbase.conf、kingbase.auto.conf、数据库级设置、角色级设置、启动参数或当前会话。只查看配置文件无法确认实例最后采用了哪个值。调整参数前先弄清当前值、默认值、参数作用范围和生效方式同时检查数据库级或角色级设置是否覆盖了全局配置。支持在线修改的参数也应先在测试环境验证。生产变更尽量安排在低峰期完成后继续观察日志、连接数和核心业务 SQL。下面的查询可以集中查看常用参数的当前值和单位SELECTname,setting,unitFROMsys_settingsWHEREnameIN(max_connections,shared_buffers,work_mem,maintenance_work_mem,wal_level,archive_mode,archive_command)ORDERBYname;以下命令会修改全局配置不要放进只读巡检脚本ALTERSYSTEMSETwork_mem8MB;SELECTsys_reload_conf();SHOWwork_mem;也可以从操作系统侧重新加载配置sys_ctl reload-D/home/kingbase/KingbaseES/V9/data需要重启才能生效的参数应安排维护窗口。常用启停命令如下sys_ctl start-D/home/kingbase/KingbaseES/V9/data sys_ctl stop-D/home/kingbase/KingbaseES/V9/data sys_ctl restart-D/home/kingbase/KingbaseES/V9/data启动后除了检查命令返回码还要确认进程状态和控制文件信息ps-ef|grep[k]ingbasesys_controldata-D/home/kingbase/KingbaseES/V9/data连接和认证配置也属于运行基线。监听地址和端口按实际需要开放认证规则按来源地址、数据库和用户分别设置。跨网络访问建议启用 SSL并把证书有效期纳入日常检查。三、内存和存储按实际负载规划内存配置需要结合共享内存、单会话内存、并发连接、后台进程和操作系统预留空间一起计算。某个参数单独看并不大但在高并发场景下会被成倍放大。调整内存前先收集这些数据物理内存和 Swap 使用情况当前活跃连接数和历史峰值排序、哈希及维护操作的并发量自动清理进程可能占用的内存操作系统页缓存和其他进程所需空间数据库侧先查询相关参数SHOWshared_buffers;SHOWwal_buffers;SHOWwork_mem;SHOWmaintenance_work_mem;SHOWtemp_buffers;SHOWmax_connections;操作系统侧同时采集内存、Swap 和进程占用情况free-mswapon-spsauxc--sort-%mem|head-20ipcs--human-a准备调整时应按并发规模估算总量。下面的数值只用于展示语法不代表推荐配置。其中shared_buffers一类参数通常需要重启后生效。ALTERSYSTEMSETshared_buffers8GB;ALTERSYSTEMSETwork_mem8MB;ALTERSYSTEMSETmaintenance_work_mem512MB;存储规划不能只看数据目录总容量。数据文件、WAL、归档、备份和日志的增长速度不同分开监控更容易判断风险。有条件时可以把高 I/O 路径放到独立存储。表空间主要用于容量和 I/O 隔离。创建前应明确用途、容量上限、备份方式和恢复路径避免为了目录拆分而增加管理复杂度。日常存储检查至少包括容量、inode、WAL 目录和 I/O 延迟df-mdf-idu-sh/home/kingbase/KingbaseES/V9/datadu-sh/home/kingbase/KingbaseES/V9/data/sys_wal iostat22iotop-b-k-P-n4如果文件系统容量正常但数据库仍有大量 I/O 等待可以继续检查多路径、挂载参数和块设备信息multipath-llmountls-l/dev/disk/by-uuid四、备份是否可用需要通过恢复确认备份任务显示成功只能说明任务执行完成不能直接说明数据可以恢复。一套可用的备份方案通常包括基础备份、连续 WAL 归档、保留策略、异地副本和定期恢复演练。先查看归档参数的实际值SHOWwal_level;SHOWarchive_mode;SHOWarchive_command;启用归档时archive_mode应为on或alwaysarchive_command需要把 WAL 实际写入可靠存储。如果命令只返回成功而文件没有落盘问题通常要到恢复时才会暴露。检查备份时不要只确认文件是否存在还要核对最近一次全量和增量备份是否完成WAL 是否持续归档备份集和归档的保留周期是否匹配备份存储是否有足够容量恢复所需的配置、密钥和工具是否齐全是否在隔离环境完成过恢复验证手动切换一次 WAL可以检查归档链路是否正常SELECTsys_switch_wal();执行后检查数据库日志和归档目录。使用sys_rman的环境还可以执行只读检查sys_rman-config/home/kingbase/kbbr_repo/sys_rman.conf\--stanzakingbase info sys_rman-config/home/kingbase/kbbr_repo/sys_rman.conf\--stanzakingbase checkgrep-rnarchive-push/home/kingbase/KingbaseES/V9/data/sys_log sys_controldata-D/home/kingbase/KingbaseES/V9/data恢复演练前保存当前环境信息恢复后使用同一组查询核对数据库、对象数量和关键业务数据SELECTversion();SELECTcurrent_database();SHOWdata_directory;SHOWarchive_mode;SHOWarchive_command;演练时要记录实际 RPO 和 RTO。业务要求 RPO 接近 0需要确认 WAL 链完整业务要求快速恢复则要记录从发现故障到服务恢复的真实耗时。文档中的目标值需要用演练结果验证。五、主备检查不能漏掉复制槽检查主备环境时只看节点是否在线不够。流复制可能仍在运行但延迟已经超过业务可接受范围。备库异常后复制槽也可能长期保留 WAL最终占满磁盘。复制状态可以按分钟采集SELECT*FROMsys_stat_replication;将差距换算成字节后更方便接入监控系统SELECTapplication_name,client_addr,state,sync_state,replay_lsn,sys_wal_lsn_diff(sys_current_wal_flush_lsn(),replay_lsn)ASlag_bytesFROMsys_stat_replication;主要关注state、sync_state、发送与回放位置以及主备之间的 LSN 差距。告警阈值应按业务允许的数据延迟设置不同环境不必共用同一个数值。复制槽可以每 10 分钟检查一次SELECT*FROMsys_replication_slots;检查复制槽数量、类型和active状态。发现预期外的复制槽时先确认来源失效复制槽也应评估后再删除不能仅凭 WAL 增长就直接清理。备库还要检查standby.signal、连接配置和时间线状态。主备发生过切换或脑裂后应先判断数据是否分叉再决定旧主库如何重新加入集群。集群和备库侧可使用以下只读命令repmgr cluster show repmgrservicestatusls-l/home/kingbase/KingbaseES/V9/data/standby.signal sys_controldata-D/home/kingbase/KingbaseES/V9/data查询当前 WAL 位置SELECTsys_current_wal_lsn();六、监控数据要能回看单个时间点的指标只能说明当前状态无法判断异常从何时开始也不容易找到触发因素。监控数据至少保留一周核心系统可以保留更长时间便于与正常时段对比。查询连接数SELECTcount(*)ASconnsFROMsys_stat_activityWHEREbackend_typeIN(client backend,walsender);按用户、客户端和应用拆分连接来源SELECTusename,client_addr,application_name,state,count(*)ASconnectionsFROMsys_stat_activityWHEREbackend_typeclient backendGROUPBYusename,client_addr,application_name,stateORDERBYconnectionsDESC;查询未获取到的锁SELECTcount(*)FROMsys_locksWHEREgrantedfalse;继续查看具体等待会话SELECTa.pid,a.usename,a.client_addr,a.wait_event_type,a.wait_event,l.locktype,l.mode,a.queryFROMsys_locks lJOINsys_stat_activity aONa.pidl.pidWHEREl.grantedfalseORDERBYa.query_start;长事务需要单独监控SELECTpid,datname,query,age(backend_xmin)ASageFROMsys_stat_activityWHEREbackend_xminISNOTNULL;查找长时间执行的 SQLSELECTpid,usename,client_addr,now()-query_startASrunning_time,wait_event_type,wait_event,queryFROMsys_stat_activityWHEREstateactiveANDquery_startnow()-interval5 minutesORDERBYquery_start;查找长时间未提交的事务SELECTpid,usename,client_addr,now()-xact_startAStransaction_time,state,queryFROMsys_stat_activityWHERExact_startISNOTNULLORDERBYxact_start;事务号年龄和许可证有效期也可以加入巡检SELECTdatname,age(datfrozenxid),mxid_age(datminmxid)FROMsys_databaseORDERBYage(datfrozenxid)DESC;SELECTget_license_validdays()ASvalid_days;数据库级事务、缓存、临时文件和死锁统计SELECTdatname,numbackends,xact_commit,xact_rollback,blks_read,blks_hit,temp_files,temp_bytes,deadlocksFROMsys_stat_databaseORDERBYdatname;sys_stat_activity 中的等待事件是瞬时状态。要分析等待趋势需要周期采样或结合 KWR、KSH、日志和操作系统监控一起判断。管理员指南给出的 CPU、I/O、内存和等待事件阈值可以作为初始参考。实际告警值最好根据本系统的业务基线调整重点关注持续偏离正常区间的情况。出现问题时操作系统侧先保存一组短时采样sar-u25sar-r25sar-nDEV25iostat25top-o%CPU-i-b-n4df-mdf-i需要保留一段时间的性能数据时可以使用 nmon./nmon-f-t-s10-c360-m/home/kingbase/nmon/七、性能变慢时先排除基础问题用户反馈“数据库变慢”时原因不一定在 SQL。连接耗尽、长事务、锁等待、WAL 堆积、自动清理滞后、磁盘空间不足或网络抖动都可能表现为响应时间上升。自动清理不要随意关闭。日常应关注长事务、表膨胀、事务年龄、清理日志和 worker 使用情况。大表可以按对象设置单独阈值不宜用一组参数覆盖所有表。查看死元组较多或长期未清理的表SELECTschemaname,relname,n_live_tup,n_dead_tup,last_vacuum,last_autovacuum,last_analyze,last_autoanalyzeFROMsys_stat_user_tablesORDERBYn_dead_tupDESCLIMIT20;查看正在执行的清理任务SELECT*FROMsys_stat_progress_vacuum;统计信息过旧时可以先对单表执行分析ANALYZEVERBOSE app.orders;清理操作会消耗 I/O也可能与业务争用资源。生产执行前应确认表大小、锁影响和维护窗口VACUUM(VERBOSE,ANALYZE)app.orders;慢 SQL 分析可以按以下顺序进行确认问题发生的时间段和业务影响。收集 SQL、执行计划、等待事件和资源数据。对比正常时段的 KWR、KSH 或 nmon 数据。判断瓶颈位于 SQL、锁、CPU、I/O、内存还是网络。调整后使用相同场景复测。分析执行计划时建议同时查看实际耗时和缓冲区使用。ANALYZE会真实执行 SQL写操作应放在测试环境或者在事务保护下分析。EXPLAIN(ANALYZE,BUFFERS)SELECT*FROMapp.ordersWHEREcustomer_id10001;需要长期统计 SQL 时可以启用sys_stat_statements。这项配置涉及参数修改和重启shared_preload_libraries sys_stat_statements sys_stat_statements.track topCREATEEXTENSIONIFNOTEXISTSsys_stat_statements;详细日志会增加磁盘和性能开销。问题定位完成后应关闭临时启用的高强度跟踪避免长期占用资源。八、发生故障后先保留现场故障发生后直接重启、删除文件或修改控制信息可能会丢失定位原因所需的证据。只要业务条件允许应先保存数据库和操作系统现场再进行恢复处理。保存数据库会话状态SELECTpid,usename,client_addr,application_name,state,xact_start,query_start,wait_event_type,wait_event,queryFROMsys_stat_activityORDERBYxact_start NULLSLAST,query_start NULLSLAST;取消 SQL 对业务的影响通常小于终止整个会话可以优先尝试。以下两条命令都会改变运行状态执行前必须核对 PID。SELECTsys_cancel_backend(26212);SELECTsys_terminate_backend(26212);操作系统侧同时保存进程、磁盘和日志信息ps-ef|grep[k]ingbasetop-b-n1iostat25df-mdf-isystemctl--failedls-lh/home/kingbase/KingbaseES/V9/data/sys_log故障处理可以按以下顺序记录确认影响范围是单会话、单库、单节点还是整个集群。保存数据库日志、集群日志、系统日志、进程状态和资源数据。判断问题属于连接、锁、复制、存储、内存、CPU、网络还是数据损坏。分别记录直接原因、间接原因和根本原因。评估影响是否会扩大以及是否存在数据丢失风险。区分紧急止损措施和后续完整修复方案。重新采样指标确认业务、复制、归档和备份恢复正常。根据结果补充监控、参数、脚本或演练安排。涉及数据文件、控制文件、WAL 和时间线的操作风险较高。没有完整备份和明确回退方法时不应直接在生产环境尝试。九、巡检清单每日检查实例、集群和守护进程状态检查主备复制延迟和复制槽状态检查数据、WAL、归档、备份和日志空间检查备份任务与 WAL 归档结果检查连接数、长事务、锁等待和错误日志每周查看 KWR、KSH 或其他性能趋势报告检查表膨胀、统计信息和自动清理状态核对备份保留策略和备份存储容量检查账号、权限和异常登录复查近期配置变更及回退记录每月或每季度在隔离环境执行恢复演练验证 RPO、RTO 是否达到业务要求复核容量增长和扩容时间点检查证书、许可证和软件维护周期更新故障手册、联系人和应急流程结语这些事项本身并不复杂难点在于持续执行。比较稳妥的做法是把重复检查做成脚本和监控项把变更与演练结果留档减少对个人记忆和临场经验的依赖。故障无法完全避免但完善的监控和记录可以让问题更早暴露也能为恢复和复盘保留足够依据。不同补丁版本和部署架构可能存在差异生产变更前请核对对应版本文档并完成验证。