組提交優化

最近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組提交的優化。

大家或許已經知道MySQL

5.6中修復了組提交的bug，這個修復最早是由MariaDB開發團隊的大牛Kristian完成的，MySQL

5.6也借鑒了這樣的實現，即一次fsync可以刷新多個事務的提交。在MySQL數據庫中，組提交存在于上層binlog也存在于下層的InnoDB引擎層。來看一下組提交在MySQL

5.6中的實現：

從上圖可以看到，在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表的備份：

記錄redo日志的LSN，記為lsn1

拷貝ibdata，*.ibd表空間文件

flush tables with read

lock

記錄binlog位置，記錄當前redo日志為lsn2

unlock tables

拷貝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與備份文件的不一致。

總結

各位在使用MySQL

5.6、MariaDB

10.0、InnoSQL版本時，務必確保Xtrabackup已經升級到了2.2.3版本。最后，感謝QA組的同事們，每次在InnoSQL新版本發布前后，總能幫助我們發現很多“奇奇怪怪”的問題。

轉自http://www.innomysql.net/article/8314.html

總結

以上是生活随笔為你收集整理的xtrabackup mysql 5.6_MySQL 5.6对于Xtrabackup的影响的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。