机房空调罢工那晚，我整理出夏季数据库注意事项

去年7月中旬的一个周二，晚上十一点多，手机连着震了三下。机房温度从24℃爬到39℃，一台MySQL主库的磁盘温度冲到51℃。原因是楼顶空调室外机高温保护停机了。那天我蹲在机房里拿风扇吹了两个小时，事后把所有能想到的夏季隐患翻了一遍，顺手整理成了这份清单。

高温最先干掉的是硬盘

很多人盯着CPU温度，其实夏天最容易出事的是机械盘和SSD。Backblaze那份年度报告里提过，硬盘温度长期超过40℃，年故障率明显抬头。我自己的统计也差不多：那台报警的主库盘，平时温度在34℃上下，那天飙到51℃之后虽然没立刻挂，但两个月后扫出了坏道。所以别等它报警，温度本身就是个慢性的东西。

机房温度这块，ASHRAE给的推荐区间是18到27℃，湿度40%到60%。我们后来把空调设定从24℃调到22℃。看着是浪费电，实际换来的是容错空间。空调一旦出问题，从22℃升到30℃要一个多小时，够你反应了；要是本来就在27℃，十分钟就顶格。

• 机柜前后都装温度探头，别只看机房整体温度，热点往往在某个机柜顶部
• 磁盘温度和机房温度接进监控，27℃预警、30℃告警、35℃直接打电话叫人
• 空调每年5月前做一次保养，滤网、冷媒、室外机散热片都过一遍
• 备两台大功率工业风扇，别笑，真出事的时候能顶一阵

雷雨天和用电高峰的坑

夏天另一个高频问题是电。雷击、市电波动、UPS切换，这几样凑一起，数据库最怕写到一半断电。我见过一次雷雨夜，UPS切换瞬间电压抖动，一台服务器直接重启，InnoDB还在做redo log恢复，业务停了将近二十分钟。后来我们改了策略：UPS电池每年测一次带载能力。铅酸电池在30℃环境里寿命差不多是25℃时的一半，夏天机房热，老化更快，别等它真断了才发现撑不住。数据库参数上，sync_binlog和innodb_flush_log_at_trx_commit按业务能接受的丢数据量来配，别为了性能全设成0，夏天停电概率高，这个代价不划算。

还有备份。我们现在的做法是每天凌晨全备，binlog实时同步到异地，每季度做一次真实恢复演练。注意是"真实恢复"，不是看备份文件大小对不对。去年演练的时候才发现，有个库的备份脚本半年前就写错了路径，一直在备一个空目录，谁都没发现。

最后说个容易被忽略的点：夏天运维人员自己也会松懈。空调坏了没人报，因为办公室里感觉不到。我现在要求值班的人每天上午十点和下午三点各看一眼监控面板，两分钟的事，比事后救火便宜太多。