GBase 8c 数据库的运维 本质上就是围绕三件事反复做集群状态要看得见、故障要能自愈、数据要能回来。本文不谈概念只讲一线可落地的动作。一、先明确运维对象角色职责运维关注点CN接收 SQL、生成分布式执行计划、下发 DN 并汇总结果连接数分布、路由均衡DN数据实际存储与本地执行通常一主多备主备状态、复制延迟、数据倾斜、磁盘水位GTM全局事务号与快照管理主备同步状态、单点风险GHA_SERVER高可用服务负责节点心跳探测、状态决策与主备切换leader 是否唯一、与 DCS 连接是否正常DCSetcd保存集群拓扑与主备状态承担多数派仲裁成员数、leader 是否健康、磁盘延迟、时钟同步分布式版的高可用由 GHA 统一管理日常操作入口是gha_ctl。这里有一条必须建立的前提DCS 是整条高可用链路的地基。etcd 对磁盘 IO 延迟和时钟漂移极其敏感建议使用独立 SSD 部署且不要与高 IO 组件混布——DCS 抖动会直接表现为误判切换。二、日常巡检用工具替代人工检查GBase 8c 提供了成套巡检工具手工翻目录、查进程的做法基本可以淘汰。1. 集群整体状态gha_ctl monitor all -H -l http://dcs_ip:2379​-H以表格形式输出重点看每个实例的state应为 running与roleprimary / standby。出现非 running 状态立即进入故障处置流程不要等下一轮巡检。需要细分时可将all替换为coordinator、datanode、gtm、server、dcs。2. 高可用链路状态gha_ctl monitor server -l http://dcs_ip:2379 # gha_server 的 leader 是否唯一 gha_ctl monitor dcs -l http://dcs_ip:2379 # 期望集群状态为 healthy​DCS 成员数不足半数、或clusterState非 healthy 时自动切换能力已实际失效。这是最容易被忽略的隐患数据库进程一切正常监控大屏全绿但故障真正发生时切不过去。3. 操作系统层体检gha_preinstall -i A​覆盖 CPU 特性、内存大页与 swap、磁盘调度策略、网卡与防火墙、时钟源、内核参数等。主机层问题是数据库层问题的常见根因——例如透明大页未关闭或交换分区被使用往往直接表现为查询抖动节点间时钟未统一则会影响 DCS 仲裁与主备判定。4. 数据库层体检gs_check -i CheckCPU,CheckMemory,CheckSpace -U gbase​建议按三个频率执行巡检避免每日全量投入过高频率动作每日集群状态、GHA 与 DCS 状态、告警清零、备份任务成功率、磁盘水位每周主备延迟趋势、慢 SQL TOP N、连接数峰值、WAL 增长速率、DCS 磁盘延迟每月恢复演练、参数基线比对、巡检报告归档、容量趋势评估三、性能诊断三层定位法分布式数据库的性能问题必须按集群层 → 实例层 → SQL 层逐级收窄跳层定位极易误判。集群层看两件事节点间是否有异常等待数据是否倾斜。倾斜可通过各 DN 记录数或表大小横向比对差异超过 20% 就值得排查分布列选择。分布列选错会导致数据在节点间反复搬运执行计划里表现为额外的Stream/Redistribute算子。实例层看活跃会话与等待事件SELECT datname, usename, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state idle ORDER BY state;​wait_event是判断瓶颈最直接的证据大量 IO 类等待指向存储LWLock 指向并发争抢ClientRead 通常意味着应用侧事务未及时提交。SQL 层看执行计划与历史语句。先用EXPLAIN (ANALYZE, VERBOSE, BUFFERS)拿真实代价重点看估算行数与实际行数的偏差偏差过大先更新统计信息而不是急着加索引。历史慢 SQL 可通过dbe_perf相关视图查询并结合 WDR 报告做时段对比——取两个快照生成报告比盯单条 SQL 更容易发现系统性劣化。四、备份恢复备份不等于可恢复方式工具粒度适用场景逻辑备份gs_dump/gs_dumpall/gs_restore库、表、模式对象级迁移、小体量导出物理备份gs_basebackup实例级全量基线、快速重建备机WAL 归档 PITR归档至独立存储增量误操作回滚、时间点恢复组件级备份gha_ctl backup/gha_ctl restore集群组件组件配置与元数据保全三个必须落地的动作与业务错峰。物理备份对 IO 压力显著放低峰窗口执行。保证分布式一致性。集群备份需保证各 DN 时间点一致不能只对单个 DN 做物理备份。定期恢复演练。备份文件存在 ≠ 能恢复。演练要真实恢复到独立环境并校验行数与关键业务表。WAL 归档目录与备份集应放在独立存储上与数据盘物理隔离否则单盘故障会同时带走数据和备份。五、高可用与故障切换DN 采用主备部署CM 负责故障检测与自动切换。运维需掌握三个动作切换前的判断。计划内切换前先用gha_ctl monitor datanode确认备机状态与复制延迟延迟过大时强行切换会造成数据回退。执行切换使用gha_ctl switchover datanodeGTM 侧同理。备机重建。备机长时间离线或日志已被清理时需通过gha_ctl build重建。全量 build 会拉起大量 IO务必放低峰期执行并确认网络带宽余量。脑裂防范。切换依赖 DCS 的多数派仲裁。DCS 成员不足半数、发生网络分区或时钟漂移严重时宁可人工介入也不要放任自动切换避免出现双主写入。推荐一个固定排查顺序先看 DCS 与 gha_server 状态再看实例状态最后看日志。跨过前两步直接翻日志通常只会拿到一堆无关堆栈。六、扩容与参数管理扩容通过gha_ctl expand datanode新增数据节点并触发数据重分布缩容使用gha_ctl shrink datanode。注意重分布阶段会带来持续的跨节点数据搬运IO 与网络占用明显上升建议分批次推进并全程监控主备延迟。扩容完成后必须复核三件事gha_ctl monitor all -H中新增节点已被纳管、DCS 成员状态正常、无残留的负载不均。参数管理有三个要求数据库参数统一用gs_guc下发禁止手工改配置文件。手工修改会绕过一致性校验主备参数不一致会直接导致备机 build 失败或切换后行为异常。集群组件参数用gha_ctl set下发并可用gha_ctl show-cfg核对生效结果避免两套参数体系相互覆盖。区分生效级别。连接数、内存类等参数属实例级需重启生效会话级参数可在线调整。变更前记录原值变更后至少观察一个业务周期。常见关注参数包括max_connections、shared_buffers、work_mem、maintenance_work_mem、max_wal_size调整原则是先有瓶颈证据再动参数避免一次性改多个变量导致无法归因。七、日志与变更纪律日志按天切分并设置保留周期。出问题时借助日志收集工具一键打包能显著减少现场来回索要文件的时间成本组件的启停与切换记录可在 GHA 侧查到这是复盘误判切换的第一手材料。最后强调一条纪律所有变更遵循三步变更前有备份、变更中有监控、变更后有回滚方案。分布式数据库的变更影响面远大于单机一个参数或一个分区动作可能同时影响多个节点。运维水平的高低不体现在处理了多少次故障而体现在故障发生前拦住了多少次。