xtrabackup mysql 5.6_网易视颇云：MySQL5.6对于Xtrabackup的影响

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PaaS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在，网易视频云与大家分享一下MySQL 5.6对于Xtrabackup的影响。

组提交优化

最近QA在对InnoSQL-5.5.30-v5版本做回归测试时发现数据不一致的问题，简单来说这个测试用例为在主机上进行全备后恢复，会发现数据不一致的情形。因为我们使用全INSERT操作来进行测试，所以可以非常简单的发现不一致的情形。但是这些测试在我们之前的v2版本中都是没有问题的。由于InnoSQL非常强调数据的一致性，因此这个问题在组内得到了极大的关注。小伙伴们测试了多个版本，发现官方MySQL 5.5、InnoSQL 5.5.20-v2版本都没有问题，但是官方MySQL 5.6和InnoSQL 5.5.30-v5版本都有这个问题。经过多方面的定位，最终确定了这个问题的源头——MySQL组提交的优化。

大家或许已经知道MySQL5.6中修复了组提交的bug，这个修复最早是由MariaDB开发团队的大牛Kristian完成的，MySQL 5.6也借鉴了这样的实现，即一次fsync可以刷新多个事务的提交。在MySQL数据库中，组提交存在于上层binlog也存在于下层的InnoDB引擎层。

在InnoDB存储引擎层每次每个事务进行prepare操作，都需要触发一次fsync操作，以此确保事务的prepare日志一定写入到redo日志(当然，InnoDB引擎本身支持组提交，可能一次fsync刷新多个事务的prepare日志，但是这个完全是无法控制的行为)。然后，一个组提交中的事务依次向MySQL的二进制日志写日志，这个写操作是缓存写，最后写完进行一次fsync操作。即一个fsync将多个事务的日志写入到了二进制日志，也就是通常所说的组提交。最后完成InnoDB引擎层面的提交操作，这个操作主要是将undo日志放入到History链表，释放锁等相关资源。但是与MySQL 5.5不同是，最后InnoDB引擎层提交操作不再需要fsync。

最后这样优化的优化也是Kristian提出并实现的，原因很简单，因为即使InnoDB引擎层的redo日志丢失，但是由于binlog日志已经写入(fsync确保)，恢复时只要确定写入binlog的日志在InnoDB引擎层全部提交即可。可以看出，这个优化进一步减少了数据库的fsync次数，从而整体上提升了数据库的性能。InnoSQL 5.5修复了组提交的bug，同时也引入了这个优化。

对Xtrabackup的影响

但是，任何优化可能都会存在一些潜在的影响。这就是为什么MySQL 5.6和InnoSQL 5.5备份会导致数据不一致的问题。我们来看Xtrabackup的内部过程，这里进考虑InnoDB表的备份：

1.记录redo日志的LSN，记为lsn1

2.拷贝ibdata，*.ibd表空间文件

3.flush tables with read lock

4.记录binlog位置，记录当前redo日志为lsn2

5.unlock tables

6.拷贝lsn1至lsn2的redo日志

但是在MySQL 5.6中xtrackup会遇到问题，因为事务最后提交不再需要fsync操作，这意味这第6步骤拷贝的日志可能会不包括那些已经在步骤4中写入binlog的那些事务，而Xtrabackup对InnoDB的恢复仅通过redo日志回放。虽然，Xtrabackup备份出来的InnoDB数据文件还是一致的，但是这些数据与binlog的位置是不一致的。那么当通过备份重新建立一个slave服务器时，就可能会导致出错。Xtrackup 2.2.3版本解决了这个问题，即在执行步骤6时，先执行一步FLUSH ENGINE LOGS操作，确保重做日志通过fsync刷新到磁盘，从而避免binlog与备份文件的不一致。

总结

各位在使用MySQL5.6、MariaDB 10.0、InnoSQL版本时，务必确保Xtrabackup已经升级到了2.2.3版本。最后，感谢QA组的同事们，每次在InnoSQL新版本发布前后，总能帮助我们发现很多“奇奇怪怪”的问题。