运维日志

Redis 默认纯内存，进程一退数据全没。RDB 快照、AOF 日志、Redis 4.0 起的混合持久化，三者取舍和坑点远比「开个 AOF」复杂：fork 内存翻倍、AOF 重写期间丢数据、文件损坏启动不了、FLUSHALL 后怎么抢时间救。从一次断电复盘讲起，把配置、取舍、崩溃恢复和运维观测拆开说。

kill -9 把进程干不掉，ps 里却还挂着一行 defunct——这类现象八成被错怪成「服务僵死」。从一次凌晨告警讲起，把信号到底是什么、为什么 -9 也会失效、僵尸进程怎么定位又该怎么回收讲透，顺带把 D 状态、孤儿进程、systemd 的信号投递这几个真正容易踩的点拆开。

早上十点，监控群炸了：订单库 CPU 直接 100%，连接池打满，前端大批超时。Redis 这边呢，命中率从平时的 98% 掉到了 20% 出头。重启应用没用，把流量砍一半也没用，DB 还是在喘。最后定位到根因——前一晚发版时，一批缓存 key 被统一刷新，TTL 都设成了 3600 秒，于是这一

有次线上两个服务之间偶尔抽风：A 调 B 的接口，大部分请求几十毫秒回来，但每隔一阵就有几个请求卡到两三秒，甚至直接连不上。ping 是通的，telnet 端口也是通的，应用日志里只看到「调用超时」。这种问题如果只盯着应用层，会一直陷在「是不是代码有 bug」里转圈。 后来在 A 所在机器上抓了

PostgreSQL 的大版本（10→12→15→16）catalog 不兼容，没法像小版本那样 yum update 后直接起。早年大家靠 pg_dump 导出再导入，几百 G 的库停机大半天。pg_upgrade 走的是「复用旧数据文件」的路子，copy 模式原样搬、link 模式直接建硬链接，停机往往压到几分钟。但它不是傻瓜命令——扩展版本不对、locale 不一致、表空间映射错一点，升级就中途报错回退。

一台数据库机凌晨无故重启，uptime 比预期短、dmesg 戛然而止，典型的 kernel panic 现场。用户态工具这时全没用——进程都没了，日志也没来得及落盘。能留下线索的只有 kdump：它靠 kexec 在崩溃瞬间切到一个预留内存里的捕获内核，把整台机器的内存 dump 成 vmcore。再配合 crash 工具反汇编栈、看 RIP、查 slab，才找得到是哪段内核代码、哪个驱动把事搞砸的。