数据库热备：3个细节别忽略

备份文件躺在那儿好好的，真出事的时候能用的没几个——这话听着难受，可冷备和热备的差别就在这儿。冷备得停服务、拷文件，数据库热备是让主库一边跑着一边把变更推到备库上，真切过去的时候业务基本无感。方向肯定没错，但落地之后有三个细节特别容易被跳过，出问题也偏偏都出在它们身上。

数据库热备的第一步，不是装同步软件

不少教程上来就让你改 my.cnf、开 binlog，但先想清楚一件事：这个“热”的范围到底多大。是整实例全同步，还是只同步业务在用的那几个库？binlog 格式用 ROW 还是 MIXED，这跟数据一致性直接相关，别图省事随手填个默认值就走。还有 binlog 的保留时间，从库要是断了几天再回来，日志早被清了，那就只能重做全量——大库重做全量可不是几分钟的事，业务能不能扛住那个窗口，得提前问清楚，别等真断了才现算。

全量初始化那一步也别偷懒。mysqldump 对付小库还行，数据量上去之后导出慢、还占锁，用物理备份工具（XtraBackup 这一类）更稳一些，具体命令、参数和版本兼容性以工具官方文档为准。磁盘 IO 和带宽也顺手看一眼，从库要是一直追不上，很多时候不是配置写错了，是盘太慢。

主从延迟：灯是绿的，数据不一定齐

从库的 IO 线程和 SQL 线程都在跑，监控面板一片绿，这就能说明复制没问题吗？未必。Seconds_Behind_Master 这个值在大事务面前是会骗人的，有时候它显示 0，实际上从库还在那儿啃一个跑了几十分钟的批量更新。看延迟我更建议直接比位点或者 GTID 差集，哪个准用哪个，别只信一个数字。

延迟的来源就那么几个：主库上没人管的大事务、批量 DDL、从库上还挂着别的读请求把 IO 抢走了。真对延迟敏感，从库上就别再塞重查询，想把读压力摊出去，多开一个只读实例比什么都实在。还有一点常被忽略——早高峰做批量导入，等于给复制链路添堵，能挪到低峰就挪一挪。

切换脚本，别等出事那天才第一次跑

这一条最容易被忽略。复制配好了，从库跑起来了，就觉得高枕无忧。可主库真挂的那一刻，谁去把 VIP 漂过来？应用的连接串要不要改？域名要不要切、TTL 设了多久？旧主库修好之后数据怎么回灌、会不会把新主库的数据覆盖回去？这些问题平时不琢磨，出事的时候就是在群里干着急。

我的建议是切换流程写成脚本，但更要紧的是定期跑一遍，起码一个季度一次。演练别只测“能不能连上”，拿一条真实的写请求从头走一遍：写进去、读出来、换个节点再读。卡在哪一步就把哪一步补上，跑通过一次，心里才算有底。

复制账号和防火墙，最容易埋雷的地方

复制账号给到 REPLICATION SLAVE 这个权限就够用了，别顺手甩一个 ALL 过去，账号万一泄露你会后悔。从库记得开 read_only，有条件再叠一层 super_read_only，防止有人手抖直接往从库写数据——一旦写进去，两边就分叉了，后面越同步越乱，还得靠工具去修。

防火墙那头逻辑一样：主库的 3306 只放从库的 IP 进来。主库换了机器、换了内网地址，白名单没跟着改，复制线程就静悄悄断了。这种断法不报错、不弹告警，往往等到真要切的时候才发现备库落后一大截。

异步、半同步、组复制，选哪个

MySQL 默认的异步复制，主库写完就返回，不等从库确认，性能最好，极端情况下会丢最后那点数据。半同步会等至少一个从库收到日志再返回，丢数据的窗口小很多，代价是写延迟上去一点，从库全卡住的时候还可能把主库写阻塞，这个坑要提前知道。组复制的一致性更强，部署和运维复杂度也跟着上去，小团队一上来就搞这个，容易把自己绕进去。

怎么选，看业务能承受丢多少数据，也看手里有多少人。没有标准答案，别人云亦云的照抄一份配置就完事。

数据一致性，靠校验兜底不丢人

前面几步都做好了，主从数据就一模一样了吗？也未必。网络抖一下、复制线程重启一次、有人误操作一回，都可能让两边悄无声息地分叉。定期做一次一致性校验很有必要，pt-table-checksum 这类工具能帮你比对差异，但校验本身在主库上有开销，低峰期跑，参数怎么调以工具官方说明为准。

工具之外，业务层再叠一层对账更让人放心——关键表每天的记录数、金额汇总对一遍。数字对不上，比任何一条监控曲线都直白。

监控告警，别只盯进程活着

监控最容易犯的错就是只盯“进程在不在”。复制线程断了，mysqld 照样活着，端口照样能连，业务读起来也没什么异常，等你发现的时候数据已经差了一大截。该盯的是复制的位点差、延迟趋势、从库磁盘还剩多少、binlog 目录会不会被撑爆，还有主库的写入量有没有突然飙起来。

告警规则定了还得想一件事：半夜响起来谁处理。没人接的告警等于没有，一条告警连着发三遍没人看，下回就真没人看了。

数据库热备不是配一次就完事的活儿，它是套得有人定期喂着的状态。要是现在就想动手，可以先做一件事：把从库拉起来，拿一条真实的写请求，把切换流程从头到尾走一遍，卡在哪补哪。顺便找个时间，把备份文件真的恢复一次试试——没验证过能不能恢复的备份，跟没有也差不太多。