Linux数据库环境搭建：七步稳态实战指南

　　我越来越觉得“Linux数据库环境搭建：七步稳态实战指南”是错的。

　　不是步骤太多，是它根本没资格叫“稳态”。去年三月，我在东莞松山湖给一家做工业网关的客户搭 PostgreSQL 集群，用的就是那本红皮指南——第七步做完，监控上 CPU 一直飘在 87% 上下，主库 wal_sender 进程隔两小时就挂一次。运维小张蹲在机柜前啃冷包子，我说：“按指南走的，肯定稳。”他抬头看我一眼，没说话，但手往旁边工位一指——老李正拿 root 权限在 /proc/sys/vm/swappiness 下打补丁，指甲缝里全是油灰。

　　我原以为七步走完就能交钥匙，结果第七步刚敲完 reboot，第三天凌晨三点告警：pg_stat_replication 显示备库 apply_delay 突然跳到 42 分钟。我连 ssh 都没敲完，就听见电话那头老李说：“你配的那个 shared_buffers，值设成 32GB？物理内存才 64GB，还开着 NUMA，你自己查查 pg_controldata 输出里那个 ‘Latest checkpoint location’ 是不是卡在同一个 LSN 两天没动过？”

　　那晚我翻了十三遍 pg_buffercache，查了五次 dmesg -T | grep -i “oom”，最后发现真正杀掉 wal_sender 的不是高负载，是内核在 reclaim page 时反复踢掉 buffer cache 里的 shared_buffers 页面，而 pg 重载时又拼命把它们从磁盘拖回来——这中间根本没人在意 pg_hba.conf 里那一行 hostssl all all 10.128.0.0/16 scram-sha-256 后面，被同事手抖多打了一个空格，导致 SSL 握手失败率 17%；也没人在意 initdb 时 locale 设的是 zh_CN.utf8，可客户应用发来的 timestamp 字符串里带的是 ISO 8601 带 T 的格式，PostgreSQL 解析慢得像冬天结冰的水管。

文章配图，仅供参考

　　指南说“第七步：启用归档并验证一致性”。我启了。归档目录权限是 700，归档命令写的是 pg_archivecleanup，实际执行日志里却跳出一行“could not rename file '000000010000000F000000AB' to '/archive/…'：Permission denied”。不是权限问题——是 NFSv4 mount 选项漏了 noac。但没人告诉你，noac 一加，readahead 就废，wal_reader 进程延迟就上来了。这事我没验，只扫了一眼归档日志里有没有 ERROR 字样，有，我就划勾。现在想想，那不是验收，是签字画押替它背锅。

　　更滑稽的是第二步：“创建专用系统用户”。我建了 pguser。但 /etc/security/limits.conf 里 soft nofile 65536 那行，我抄的时候顺手删了末尾的 # ulimit -n，导致上线三天后，连接池突然拒绝新连接，ps auxf 显示 postgres 进程底下吊着三百多个 子进程——原来那是连接未正常 close 就退出的后遗症，而 pguser 的 limits 始终卡在系统默认的 1024。技术总监老周来巡检，拿手机拍下 top 输出，甩过来一句：“你们性能组管‘搭建’，不管‘活着’？”

　　去年十一月我复盘时重新跑了那套环境，同一台机器，同样的内核版本，同样的 PostgreSQL 14.5，我把指南七步全砍掉，只留四件事：先用 pstack 抓住 postgres 主进程在做什么；再翻 sysctl.conf 把 vm.dirty_ratio 改成 15（他们用的是三星 PM9A3，压测时 dirty page 刷得太懒）；接着用 strace -p 跟 wal_sender 三分钟，发现它卡在 connect() 上——原来 DNS 服务器没配，超时设的是 30 秒；⭐️⭐️⭐️⭐️手动把 wal_level 改成 replica 后 reload，不是 initdb 重来。那台机器跑满三个月，pg_stat_bgwriter 里 checkpoints_timed 始终为零。不是不触发检查点，是根本不需要定时触发。

　　所以说“七步”这个数本身就很可疑。真需要七步？还是为了凑页码方便排版？我上个月在杭州跟一个 DBA 对线，他说他们公司把指南印成册子发新人，扉页写着“稳态基石”。我指着他们生产库 pg_settings 里 log_min_duration_statement = -1 这条记录问：“你们基石上连慢查询都懒得记？”他眨眨眼：“啊，这条……是不是该开？”

　　指南里那个 nginx 反向代理 PostgreSQL 的示意图，我去年在珠海见过一次真实部署——用 nginx 做 pgpool 的前端，结果 pgpool 自己的健康检查 timeout 设置比 nginx 的 proxy_read_timeout 还短三秒，整个集群切主时，nginx 缓存了旧连接状态，客户端看到的是“server closed the connection unexpectedly”。当时值班的是个实习生，他按指南第七步重启 pgpool，然后在群里发了个截图：curl -I http://pglb/api/health 返回 502。没人问他为什么不用 tcpdump 看三次握手断在哪。

　　现在我知道了，“优胜劣汰”那部分确实站得住——熬过三年、还在用这指南的人，要么换岗了，要么自己偷偷重写了脚本。我桌上还放着那本红皮书，封底被咖啡渍泡软了边，但我不扔。等哪天遇到更狠的坑，我打算把第七步撕下来，贴在服务器机柜门内侧。旁边再贴张便签，写：“别信步骤数，信你的 dmesg，信你 ps 看见的 RSS，信你亲手 kill -3 过的 postgres 进程里到底有多少个 LWLock。”

　　这事我也可能就运气好——碰巧那个月没遇上 ext4 文件系统 journal 模式切换失败，也没撞上 kernel 6.1 里那个已知的 cgroup v1 内存统计偏差 bug。下回就不一定了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!