今日关键词：MySQL从库备份导致CPU 100%、锁表排查、Full GC风暴、级联故障分析、线程池耗尽、备份锁表、DBA故障复盘
凌晨3点，手机突然弹出CPU 100%告警。瞬间睡意全无，脑海中闪过无数可能性：慢SQL？连接风暴？还是恶意攻击？直到亲手完成故障排查，才发现根源出人意料地“常见”——仅仅是从库的一个备份任务。
今天，我把这次完整的故障复盘整理成文，希望能为你提供一些借鉴。
故障时间线
凌晨3点15分，CPU 100%告警触发。打开监控发现，Java应用的CPU已被彻底打满，JVM堆内存的Old区几近饱和，Full GC每隔几秒就触发一次。
第一时间怀疑慢SQL。连上数据库执行SHOW PROCESSLIST;，结果令人震惊：大量查询的状态全部显示Waiting for table lock，连接池直接被占满。接着查询锁情况：
SHOW ENGINE INNODB STATUS;
很快，一个熟悉的关键词映入眼帘：FLUSH TABLES WITH READ LOCK。从库正在执行物理备份，该命令会锁住全库。所有读查询全被挡在外面，一个接一个排队等待。
根因：从库备份引发锁表
问题出在备份策略上。物理备份工具在执行时，依赖FLUSH TABLES WITH READ LOCK来获取数据文件的一致性快照。但这个操作的代价是：在锁释放前，所有查询都会被阻塞。
此时，主库写入完全正常，从库的应用日志也在正常推进。但应用侧发往从库的读请求，全部因超时而堆积。
完整故障链
这起故障属于典型的级联故障，每一步单独看都不致命，但叠加起来，就足以让整个服务崩溃。
一切从备份锁表开始。FLUSH TABLES WITH READ LOCK获取全局读锁后，从库上的所有读查询全部被阻塞。查询进来了却无法执行，只能在连接池里排队等待。
问题来了：每个排队中的查询，都对应着一个JDBC连接和一个ResultSet对象，它们都占用着内存。查询量持续增长，线程池里的活跃连接数一路飙升，堆内存迅速上涨，Old区很快被打满。
到这一步其实还有救。但JVM发现Old区满了，开始疯狂触发Full GC。问题在于，那些被阻塞的线程对象根本回收不掉——它们还在“活着”，依然在等待锁。GC反复执行，但什么也回收不了。
尝试用jstat -gcutil 看了一眼，Full GC次数飞速增长，每次回收后的Old区占用几乎没降。这是典型的“GC风暴”：GC线程和业务线程争夺CPU，但业务线程都在等锁，CPU资源基本全被GC消耗掉。
最终结果：Java应用线程池耗尽，CPU 100%，服务完全不可用。从一次备份锁表到整个系统瘫痪，一环扣一环，每一步都不致命，但叠加起来就成了灾难。
快速止血
找到从库正在执行备份后，第一反应是：先止血再说。
第一步，杀掉从库的备份进程，释放全局读锁：
# 找到备份进程
ps aux | grep xtrabackup
# 杀掉进程
kill -9
第二步，重启Java应用，等待线程池释放，GC恢复。
从发现问题到恢复服务，花了将近20分钟。老实说，当时心里有些慌乱，走了不少弯路。如果监控更完善，定位速度可以快得多。
后续改进措施
止血只是第一步，根因不解决，故障迟早会重演。
回过头看，最该后悔的是没早点更换备份方案。FLUSH TABLES WITH READ LOCK属于老方案，锁全库这个特性平时不觉得有问题，一出事就是大事。后来换成XtraBackup，备份期间不锁表，从根源上杜绝了隐患：
# XtraBackup 热备份，无需全局锁
xtrabackup --backup --target-dir=/data/backup/
同时，补充了备份监控。备份开始和结束都记录时间，超过预期时长立即告警，不能等出了事再查。
连接超时也做了调整，从30秒降到10秒。之前设得太长，请求排队30秒才超时，积压量翻了好几倍。
最后是告警分层。之前只盯CPU和数据库延迟，线程池和内存完全没有监控。这次补上了：线程池使用率达到80%就告警，别等到100%才反应过来。
核心教训
回头看，这次故障其实挺冤的。
备份策略居然没有评估过锁表影响。备份方案选型时只看了“能不能备份成功”，没想过备份期间对业务有什么影响。这是最关键的失误。
监控也缺了一大块。平时只盯CPU和数据库延迟，线程池和内存根本没管。这次jstat的Full GC数据是排查的关键线索，但之前从来没看过这个指标。连接超时也设得太长，排队30秒才超时，积压起来根本刹不住。
此外，从库读请求缺少降级机制。数据库一挂，应用也跟着挂。如果应用侧有熔断，至少写入不会受影响。
排查的突破口是jstat的Full GC数据异常。顺着GC找到线程积压，再顺着线程找到锁表。思路和常规排查一致：先看现象，再一层层追。
避坑清单
- 备份方案选型时，先搞清楚备份期间数据库还能否正常服务。不是“能备份”就行。
- 生产环境首选XtraBackup这类热备份工具，备份期间不锁表。
- 连接超时设太久，故障时请求会疯狂排队。积压比故障本身更致命。
- 线程池使用率80%就该告警，等到100%服务已经挂了。
- 数据库超时要有熔断，不能一个故障拖垮整套服务。
jstat的GC数据别忽略，异常时能帮你快速缩小排查范围。- 备份任务要监控时长，超时说明有问题，不能等出了事再查。
- 告警要分层。CPU、线程池、内存、IO都要覆盖，只盯CPU会漏信号。
- 凌晨3点先止血拉服务，根因白天再慢慢查。恢复永远优先排障。
- 不复盘的故障迟早会重演。
这次最深的一个体会是：备份方案不能只看“能不能备份成功”。备份期间对业务的影响，才是真正的评估重点。级联故障的触发条件往往很普通——一个备份任务，一个锁表操作，每个环节单独看都没什么大不了，但叠在一起，系统就扛不住了。
从排查工具到真实故障场景，两篇结合起来，下次遇到CPU 100%就能从容应对。
