运维日志

早上十点，监控群炸了：订单库 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，才找得到是哪段内核代码、哪个驱动把事搞砸的。

一台 MySQL 半夜告警磁盘 100%，一查是 datadir 下躺着三百多个 mysql-bin.000xxx，每个 1G，占了 300 多 G；另一次，同事手滑 DELETE 没带 WHERE，五千条订单没了。两件事的命门都是 binlog——它既是吃爆磁盘的元凶，也是救回误删数据的唯一希望。本文把 binlog 的格式选择、GTID、过期清理、磁盘爆满救急、误删闪回恢复，以及主从环境下不能乱 PURGE 的坑，一次讲透。

一台 64G 内存的机器，内存才用到一半，响应却一卡一卡，iotop 里 kswapd 占着 CPU 狂写磁盘——这病九成出在 swap 上。很多人对 swap 的理解还停在「内存不够时的备胎」，对 swappiness 的理解停在中「调成 0 就不换出了」。两者都错。本文从一次线上卡顿讲起，把 swap 到底在干嘛、swappiness 的真实含义、怎么加 swap 文件、怎么诊断 swap 风暴、不同业务怎么调，以及关 swap 的代价一次讲清。