运维日志

一台 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 的代价一次讲清。

线上昵称里带个 emoji，存进库变成 「ðŸ」；一次迁移之后，原本正常的客户备注全成了 「???」。这种字符集乱码，八成不是「数据库坏了」，而是 server、database、table、column、连接层五层字符集没对齐。MySQL 的 utf8 其实是 3 字节的假 utf8，存不了 emoji，真正能存全 Unicode 的是 utf8mb4。从现象反推根因，顺手把已经乱掉的数据救回来。

凌晨两点，一台共用机器 load 飙到 80，SSH 都卡。查下来是个批处理脚本 fork 爆炸，把整台宿主的 CPU 和内存吃光。这种「一个进程搞死全机」的事，ulimit 管不住、nice 降优先级也只是缓解。真正的答案是 cgroup v2——配合 systemd 的 resource control，给每个服务画好 CPU、内存、IO 的硬边界，谁越界谁先死，绝不连累邻居。

PG 跑几个月后表体积翻了好几倍、查询越来越慢，但数据量没怎么涨——多半是 MVCC 死元组没清掉，表膨胀了。讲清死元组怎么来的、怎么量化膨胀率、autovacuum 为什么没跟上，以及手动 vacuum / 重建表 / 参数调优的具体操作，附我线上踩过的坑。

进程卡住不动、接口莫名变慢、启动就报权限拒绝——这些毛病用 top 看不出所以然。strace attach 上去追踪系统调用，能直接看到进程卡在哪个 syscall、等了多久、读写是否正常。本文讲清 attach、过滤、-e 表达式、耗时统计，以及线上不敢随便 strace 时的替代打法。