Question

MySQL双主复制的主备数据一致性知多少

Answer 1

　　

　　为提高MySQL服务器提供数据服务的可用性和可靠性，实际生产环境中，大量使用简洁易行的异步数据复制技术，且多采用双向复制的架构，以便做到自动或人力快速切换的效果。关于MySQL的数据异步复制技术的数据一致性，在推出支持基于行、混合模式复制之后，是否真如手册所言，彻底解决数据复制的一致性呢？关于二进制日志登记模式的知识，大家可以阅读曾写过的文章，超链接地址：解读MySQL事务的隔离级别和日志登记模式选择技巧。

　　自从本人使用mysql复制技术以来，就一直对业务场景为：用户自身的操作行为，会使用户之间的数据操更改存在交叉行为，若使用双向复制的架构，但是不要对数据库的更新操作进行负载均衡，也即更新操作会均衡或非均衡方式，发送给2台服务器同时进行处理，而应该坚持把写操作只发送给其中一台数据库服务器或称MASTER的数据库服务器。常用的双向复制技术架构，按处理读写业务方式分，有三种提供数据服务的方式，如图1-1：

　　建议大家使用图1-1中的前二种方式，第三种提供数据服务的方式，在大多数业务场景下，建议大家谨慎使用，主要是指用户自身的操作行为，能触发程序不仅修改自身的数据信息，还会修改其他用户的数据信息的场景。那么接下来的内容，将给大家介绍MySQL基于行、混合模式数据复制的架构中，Slave端的SQL线程是如何根据从Master端读取的二进制格式的SQL语句，更新Slave端的数据。转载

　　

　　

Answer 2

XtraBackup 在 MySQL 备份场景中被广泛使用，大家一定不陌生。我们也在之前的两篇文章中分享了其备份的原理。（详见 [原理解析] XtraBackup全量备份还原 & [原理解析] XtraBackup增量备份还原）本文想要描述的是 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)。所有增备恢复完成后的数据也是完整的。