Linux数据库环境搭建：七步稳定落地实战

　　去年七月，我在客户机房蹲着配 PostgreSQL 主从，空调直吹后颈，衬衫第三颗扣子崩了——反正没人注意。

文章配图，仅供参考

　　第二步换镜像源，改成清华的，wget 拉包成功，但 dpkg -i postgresql-15_15.6-1.pgdg22.04+1_amd64.deb 报 dependency conflict：libpq5 版本对不上。老王蹲在隔壁机柜口里嚼薄荷糖，抬头说：“你装的是 15.6，他们环境里早被运维手欠卸过 libpq5——上礼拜刚清过一遍。”

　　第三步绕开 dpkg 强制装，用 --force-depends，第四步 initdb 后改 postgresql.conf：listen_addresses = '192.168.12.3,127.0.0.1'，第五步 pg_hba.conf 加两行 host replication repluser 192.168.12.4/32 md5，host all all 0.0.0.0/0 reject。第六步 systemctl start postgresql，第七步 psql -U repluser -h 192.168.12.4 -c "SELECT 1"——返回 1，主从通了。

　　可第七步跑完两小时，主库磁盘突然告警，df -h 看 /var/lib/postgresql/15/main/pg_wal 用了 98%。查 archive_command，发现脚本里写的是 rsync -avz /var/lib/postgresql/15/main/pg_wal/ backup@192.168.12.5:/backup/wal/，但 backup 用户 ssh key 在第七次重试时被权限误删，而 rsync 默认失败不报错，日志里只留了一行 exit 12 —— 就藏在 /var/log/postgresql/postgresql-15-main.log 第八次滚动文件末尾，第 4192 行，夹在两个空行之间，没人扫过。

　　我原以为 WAL 归档失败会立刻报 FATAL，结果它就静默堵着，主库还在拼命写 wal 文件，wal_keep_size=128MB 被它吞得像纸片，连 pg_archivecleanup 都救不回来。同事小林敲着键盘问我：“是不是归档路径拼错了？” 我翻他写的备份脚本注释，里头写着“此处为示意，上线前请删掉”，我忘了删。

　　其实第二步那会儿我就该看 /var/log/apt/history.log，里面记着 libpq5 被谁删的、什么时候删的；但当时盯着 dpkg 的报错行发愣，眼睛盯太死，漏了上一行——就是那个 curl 命令执行前的 timestamp。后来恢复时才发现，那条时间戳比整个机房 NTP 同步快四十七秒，所以所有日志里的时间线都飘着。

　　优胜劣汰这词站得住——不是因为谁更懂命令，是有人真把第八次滚动日志的第 4192 行当真读了，有人连第一行都没扫全。我修好 WAL 归档后重启主库，replica 自动追上，延迟归零，监控图表绿得晃眼。可当天下午三点十七分，主库进程又莫名僵住一次，ps aux | grep postgres 显示状态是 D（uninterruptible sleep），top 里 %wa 到 94，iostat -x 1 看 sda 的 await 没停过，但 pvdisplay 说 LVM 逻辑卷一切正常。我也不知道这到底算谁赢了。

　　有谁碰到过这个吗？主库在 WAL 归档修复后持续高 I/O 等待，但磁盘本身不报警，也找不到大文件在刷，就干等着，连 strace -p 都抓不到系统调用堆积点。

（编辑：航空爱好网）

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