用xtrabackup备份MySQL大表这些常见实操坑点

运维干久了人都知道，几十上百G的MySQL大表备份这事，说起来不复杂，实际一上手总能整出点幺蛾子。当初选xtrabackup就是图它能热备、不用像mysqldump那样锁表卡业务，但真用起来才发现坑一点都不少。比如备份跑着跑着磁盘满了，整个任务直接挂掉；或者费了半天劲备出来的文件，到恢复的时候死活打不开；更头疼的是，以为热备不影响业务，结果线上查询突然变慢，被骂半天才反应过来是备份把IO吃光了。这些场面我估计不少人都经历过，下面就把几个经常被忽略的细节理一下，省得大家再栽跟头。

备份前忽略磁盘空间预检查

很多同学习惯上来就直接敲备份命令，压根没看一眼备份目录还剩多少磁盘。几十G上百G的大表备份，不光要放完整数据集的拷贝，过程中生成的临时文件、事务日志啥的也要吃掉不少地方，磁盘剩余空间没个待备份表空间的1.2倍以上，真的可能跑到一半就满了。这时候备份中断倒还是小事，麻烦的是那块盘上可能还跑着别的服务，一满盘全跟着受影响，运维群里的报警能炸锅。所以动手之前先df -h一下，心里有个数，再让备份跑起来，能少很多半夜扩容磁盘的糟心活。

备份参数配置不当引发业务卡顿

不少人对xtrabackup的印象就停留在“热备不锁表”这五个字上，觉得既然是热备，啥时候跑都行，备份大表也敢直接往业务高峰期塞。结果磁盘IO和CPU被备份进程全吞了，线上的增删改查请求全挤在队列里排大队，慢查询告警哗哗地往外跳，要是赶上交易类数据库，超时的单子一多，那就不是运维自己着急的事了。这种时候再怪工具就有点没道理了，主要还是参数没调好。像--throttle这种IO限流的设置，很多人压根没碰过默认就跑，压力能不大吗。我的习惯是尽量把大表备份安排在凌晨业务低谷那会儿，再根据服务器实际负载调个合适的IO限流值，让备份占用的资源别越过安全线，这样业务方基本无感知，自己也不用大清早被电话叫起来。

备份完成后跳过校验环节

还有个特常见的操作，就是看到终端上弹出备份成功的提示，顺手就把几天前的旧备份删掉腾地方，心里想的是反正新的已经备好了。可真等哪天需要恢复数据了，才发现这个备份文件因为备份期间大表还在持续读写，出了坏块或者事务日志应用不完整，恢复过程直接报错，傻眼了。那会儿旧备份又被自己亲手清空，真的是叫天天不应。所以备份完千万别急着清理，先老老实实做一遍文件完整性校验，有独立测试环境的话，最好跑个快速恢复演练，把备份文件真正用起来验证一次，确认没问题了再删旧数据。多花这点时间，跟出事时候的年假泡汤和通宵加班比，简直太划算了。

说白了这几个坑都不是什么高深技术难题，全是备份前该做的检查没做到位、参数没结合大表场景微调、备份后的校验步骤能省则省给省出来的。咱干运维的，在这些小细节上多留点心，用xtrabackup备份大表就能稳当不少，也免得给自己制造太多救火现场的刺激。