Running Postgres at Scale – 百万级用户的运维教训

运营拥有百万级用户的 Postgres 产品过程中，作者几乎踩遍了所有坑。以下是希望第一天就知道的经验：

Autovacuum 不是可选项。可以暂时忽略，但不能永远忽视。死元组不断累积，查询计划变差，原本 10ms 的查询最终变成 3 秒且原因不明。尽早调优，大表上 autovacuum_vacuum_scale_factor = 0.05 是一个好起点。
连接池不是可选项。Postgres 连接昂贵——每个连接都持有内存和工作进程。用 PgBouncer 等工具，保守设置池大小。应用可能想要 500 连接，但合理池化后 Postgres 能轻松处理 50。
长事务是沉默的杀手。打开 2 小时的事务会阻止 vacuum 清理其开始时间之后的新元组，导致表膨胀、查询变慢。对 pg_stat_activity.xact_start < now() - interval '10 minutes' 设置告警，主动杀掉长事务。
查询计划器并非魔法。它是一个成本估算器，可能出错。看到应该走索引却走全表扫描的查询时，计划器认为全表扫描更便宜，但估算可能是错的。定期 ANALYZE，增大大表的 default_statistics_target，debug 时可用 SET enable_seqscan = off。
未经过恢复验证的备份不是备份。每月用真实数据量演练恢复。作者首次尝试恢复 800GB 生产备份用了 11 小时——在故障发生前知道这一点至关重要。

Postgres 非常宽容，但只对那些尊重它的人。

#开发者 #工具 #Postgres #数据库 #SRE #DevOps #运维 #性能优化 #教训
@DevToolboxHub