07 让 PostgreSQL 跑得稳: 安全、巡检、监控与故障预防

真正稳定的数据库系统，不是“没出过事故”的系统，而是“即使出事故也能快速发现、快速定位、快速止损”的系统。很多团队以为自己在做运维，其实只是把实例跑起来了。真正的运维能力，至少要覆盖四件事: 权限边界、日常巡检、可观测性、恢复演练。

安全是最容易被低估的稳定性问题

数据库安全不只是防攻击，它直接影响系统可维护性。账号乱、权限乱、审计缺失，最后带来的不仅是泄露风险，还有排障困难和变更失控。

最基本的安全要求应该包括:

• 应用账号和管理账号分离
• 最小权限原则
• 敏感操作有明确责任边界
• 登录来源可控
• 密码、证书、连接方式有统一规范

一个很实际的判断标准是: 你能不能在十分钟内说清楚“哪个服务用哪个账号、能干什么、不能干什么”。如果做不到，风险就已经存在了。

巡检不等于看几个监控图

高质量巡检不是“看看 CPU、内存、磁盘”，而是围绕数据库真正的运行机制去看。

最值得长期跟踪的指标包括:

• 活跃连接数和等待连接数
• 长事务和 idle in transaction
• 锁等待链
• 慢 SQL 分布
• autovacuum 是否跟得上
• 死元组和膨胀趋势
• WAL 增长速度
• 检查点压力
• 复制延迟
• 备份结果和恢复点可用性

这些指标里，有些是性能问题的前兆，有些是恢复问题的前兆，有些则是业务使用方式失控的前兆。

两条特别值钱的排查 SQL

看长事务

select pid, usename, now() - xact_start as xact_age, state, query
from pg_stat_activity
where xact_start is not null
order by xact_start;

看 idle in transaction

select pid, usename, now() - state_change as idle_age, query
from pg_stat_activity
where state = 'idle in transaction'
order by state_change;

很多看起来像性能问题的故障，最后根源都在这两类会话上。

可观测性应该分三层

1. 指标

解决“哪里不对”。

2. 日志

解决“发生了什么”。

3. 跟踪和采样

解决“为什么发生”。

这三层缺一不可。只有指标没有日志，定位会很粗；只有日志没有趋势图，无法判断问题是偶发还是持续；没有采样和跟踪工具，很多高频低耗时问题会很难抓。

预防比救火更重要的几个点

1. autovacuum 不是可有可无

很多团队直到表膨胀、事务号年龄异常时，才意识到 autovacuum 不是“后台小功能”，而是 PostgreSQL 正常运行的一部分。

2. 连接数不是越多越好

连接堆高通常不是数据库强，而是应用或架构已经出了问题。数据库连接应该被当作受控资源，而不是无限池子。

3. 监控必须带阈值和动作

只画图不设阈值、只报警不配动作手册，实际效果有限。真正有效的监控，应该能直接触发明确处理动作。

一套够用的日常节奏

• 每天: 看慢 SQL、长事务、等待链、复制延迟、备份结果。
• 每周: 看膨胀趋势、热点表、热点 SQL、权限变更、失败日志。
• 每月: 做一次恢复验证，复盘慢查询治理和容量变化。

真正的运维能力是什么

不是记住多少参数，而是建立一套闭环:

• 提前看见风险
• 出问题时知道先看哪里
• 处理完之后能防止再次发生

只要这套闭环建立起来，PostgreSQL 的稳定性会比很多团队想象中更可控。