有一次，我帮一个朋友收拾他公司那台快散架的服务器。那哥们儿半夜两点给我打电话，说数据库崩了，客户资料全没了，语气里带着哭腔。我远程连上去一看，好家伙，数据文件还在，但日志文件被某个手欠的同事给清了。那会儿我就意识到，很多人对MySQL的备份恢复，理解还停留在“把文件拷出来”这个层面。今天咱就好好唠唠，MySQL数据库恢复的基础到底是个啥。
说白了，MySQL数据库恢复的基础，就是“日志”和“备份”这两条腿走路。你光有备份文件，那只是给数据拍了张照片，照片只能反映按下快门那一刻的景象。但数据库是活物，每秒钟都有INSERT、UPDATE在发生，这些操作全被记录在二进制日志（binlog）里。恢复的本质，就是用备份把数据库拉回到某个时间点，再用binlog把之后发生的事儿重演一遍，直到你想要的瞬间。所以，你要是把binlog给关了或者弄丢了，那恢复就成了瘸子走路，使不上劲。
拿我那个朋友的例子说，他其实做了全量备份，但备份是三天前的。数据库崩了之后，他想着恢复完事，结果发现这三天的交易记录全没了。这三天里，客户下的单、改的价、付的款，全在binlog里躺着呢。他没做增量备份，也忘了binlog这回事，所以只能恢复到三天前的状态，损失惨重。这就是为什么我总跟人强调，binlog不是可选项，是必选项。你要想把恢复做到“指哪打哪”，就得确保binlog开着，而且最好单独放到一块磁盘上，别跟数据文件挤在一起。
有了这两条腿，接下来就得谈具体的操作了。最基础的一招叫“物理恢复”，就是直接把备份的ibd文件、frm文件啥的拷回去。这招快，但前提是你得保证备份文件跟当前MySQL版本完全兼容，而且数据目录结构不能乱。我之前见过一个哥们儿，从MySQL 5.7备份的文件，直接扔进8.0的目录里，结果启动都启动不了，报错报得跟天书似的。所以物理恢复适合那种“原样还原”的场景，比如服务器宕机了，你拿备份文件覆盖回去就完事。
比物理恢复更常用的是“逻辑恢复”，也就是用mysqldump导出的SQL文件来恢复。这招的优点是灵活，你可以选择只恢复某个表，甚至只恢复某几行数据。操作也简单，就一句。但缺点也明显，速度慢，尤其是数据量大的时候，几百万行的INSERT语句跑起来，那叫一个煎熬。我记得有次帮人恢复一个两百多G的库，mysqldump出来的文件有八十多G，硬是跑了六个多小时，期间我还得盯着屏幕看进度，生怕哪条语句出岔子。
说到这，得提一个特别容易踩的坑：恢复前不检查GTID。GTID是MySQL 5.6以后引入的全局事务标识符，它就像是每个事务的身份证号。如果你备份的时候开了GTID，恢复的时候又没处理好，就会碰到主键冲突、事务重复执行这些幺蛾子事儿。我见过最惨的一次，是有人用mysqldump导出的备份，往一个有GTID的实例上导入，结果因为GTIDEXECUTED不一致，导致一堆事务被跳过，数据对不上账。所以，恢复之前，一定得用看一眼当前的GTID位置，然后要么清空GTIDPURGED，要么用来避免冲突。
再往深了说，恢复这件事，其实分“完全恢复”和“时间点恢复”。完全恢复就是回到备份那一刻，简单粗暴。但很多时候，你需要的不是回到过去，而是“回到某个错误操作之前”。比如有人手滑执行了，你想要的不是回到昨天，而是回到那一秒之前。这时候就得靠binlog了。你先恢复全量备份，然后把binlog里那个DELETE语句之前的日志都重放一遍，到了那个节点就停。这个操作在MySQL里叫“基于位置的恢复”，用工具能查到每个事务的起始位置，配合参数，就能精准掐断。
不过，这招虽好使，但有个前提：你得能读懂binlog。binlog有三种格式，STATEMENT、ROW、MIXED。默认是ROW，这种格式记录的是每一行数据的变化，安全，但日志体积大，而且用mysqlbinlog解析出来的SQL语句是经过转义的，看起来让人头大。STATEMENT格式记录的是原始SQL，好懂，但有时候会因为函数、存储过程之类的导致主从数据不一致。所以，我一般建议，恢复的时候用ROW格式，虽然麻烦点，但至少不会出现“恢复完了数据还是错的”这种尴尬局面。
得说说那些“恢复不了”的情况。最典型的就是误删了binlog文件。这就像是你把日记本撕了，还想回忆自己上周干了啥，神仙也难办。还有一种是备份文件本身损坏了，比如磁盘坏道导致的文件残缺，那种情况你只能求助于第三方工具，比如Percona Data Recovery Tool，但能不能救回来全看运气。所以，我一直强调，备份不是备份一次就完了，得搞“3-2-1策略”：至少三份拷贝，存在两种不同介质上，其中一份在异地。这词儿听着像口号，但真到出事那天，你就知道它值多少钱了。
回到开头那个朋友的事。我帮他翻了半天的binlog，总算把三天里的交易记录给拼凑回来了，但中间还是丢了两笔单据。他问我，怎么能做到万无一失？我说，哪有什么万无一失，你只能尽量把恢复的基础打牢——日志别关，备份勤做，恢复流程得提前演练。MySQL恢复这事儿，说穿了就是跟时间赛跑，你准备得越充分，跑赢的概率就越大。别等数据库崩了才想起看这篇文章，平时多检查检查binlog，多试几次恢复演练，比什么都强。
