图解MySQL | [原理解析] XtraBackup 备份恢复时为什么要加 apply-log-only 参数？

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《图解MySQL | [原理解析] XtraBackup 备份恢复时为什么要加 apply-log-only 参数？》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下MySQL、数据库、备份、xtrabackup，希望所有认真读完的童鞋们，都有实质性的提高。

XtraBackup 在 MySQL 备份场景中被广泛使用，大家一定不陌生。我们也在之前的两篇文章中分享了其备份的原理。（详见 [[原理解析] XtraBackup全量备份还原](http://mp.weixin.qq.com/s?__b... & [[原理解析] XtraBackup增量备份还原](http://mp.weixin.qq.com/s?__b...）本文想要描述的是 XtraBackup 恢复时参数 apply-log-only 的作用，不知道大家有没有注意到，这个参数如果不设置，可能会产生数据不一致的惨剧。

使用 XtraBackup 对数据库做备份，实际上就是拷贝 MySQL 的数据文件，为了保证备份数据的最终一致，也会同时拷贝备份过程中的 Redo log。

如图 1 所示，全备开始时，事务 2 尚未提交，Redo log 中仅有事务 2 的一部分数据(B->F)，XtraBackup 于是将这一部分数据拷贝到全备文件中。

如图 2 所示，增备开始时，事务 2 已经提交，Redo log 中有了事务 2 的完整数据。XtraBackup 于是将事务 2 的后一部分数据拷贝了下来。

如图 3 所示，恢复时，首先恢复全备中的数据文件，然后回放全备中的 Redo log，回放过程中应用了一部分事务 2(B->F)，如果没有设置 apply-log-only，XtraBackup 会在恢复最后一步应用 undo，将这一部分残缺的事务回滚(F->B)，就此埋下了祸根。

如图 4 所示，后续恢复增备文件时，继续回放了事务 2 的后一部分(E->G A->H)，导致最终的数据文件中丢失了事务 2 第一部分的数据(B->F)，惨剧就发生了。

如图 5 所示，正确的做法应该是除了最后一个增备，所有的备份恢复都应该设置 apply-log-only 参数（only 指的就是只回放 redo log 阶段，跳过 undo 阶段），避免未完成事务的回滚。如图所示，此时全备恢复后的数据文件才是完整的(包含了B->F)。所有增备恢复完成后的数据也是完整的。

参考：
https://www.percona.com/doc/p...

好了，本文到此结束，带大家了解了《图解MySQL | [原理解析] XtraBackup 备份恢复时为什么要加 apply-log-only 参数？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！