Xtrabackup介紹

1????? 介紹

percona Xtrabackup是目前比較流行的MySQL熱備份工具。其工具集中包括innobackupex、xbcrypt、xbstream、xtrabackup等。比較常用的就是innobackupex和xtrabackup。在2.3版本之前innobackupex是一個perl腳本，其封裝了xtrabackup。從2.3版本開始這個腳本的所有功能都在xtrabackup的C程序中實現(xiàn)了，為了向前兼容2.3版本開始innobackupex是一個指向xtrabackup的軟連接，并且支持其在2.2版本中的所有特性和語法，在后面的主版本中可能會去掉。

2????? Xtrabckup流程介紹

下圖是2.3版本的被流程（因為innobackup在這個版本里只是Xtrabackup的一個軟連接，圖中只展示了Xtrabackup）。

3????? 2.2.3版本之前的一個問題

Xtrabackup在2.2.3版本之前有一個bug，備份出來的數(shù)據(jù)庫是一致的，沒有問題，但是可能會導致備份出來的數(shù)據(jù)庫與binlog位置不一致。當使用binlog的位置的話，會引入一些問題。

https://bugs.launchpad.net/percona-xtrabackup/+bug/1320685

這個問題是在MySQL5.6的一次代碼優(yōu)化后Xtrabackup才有的。關(guān)于事物提交,InnoDB存儲引擎層對每個事物進行prepare操作，都需要進行一次fsync操作，以便保證事物的prepare日志寫入到了redo日志中。然后，一個組提交中的事物依次向MySQL的二進制日志寫日志，這個寫操作是緩存寫，最后完成一fsync操作。即一個fsync將多個事物的日志寫入到了二進制日志，也就是我們通常說的組提交。最后完成InooDB引擎層面的提交操作。5.6的一個優(yōu)化就是InnoDB引擎層的提交不再進行fsync。

因為即使InnoDB引擎層的提交操作丟失了，這個事物要做的事情基本已經(jīng)完成。由于binlog日志已經(jīng)寫入且已經(jīng)fsync,再恢復時，只需要從binlog中判斷最后的事物是提交還是回滾就可以。

但是對于Xtrabackup是個問題，因為事物最后的提交不再需要fsync,那么其redo日志中可能還沒有提交記錄。而Xtrabackup對于InnoDB的恢復只是通過redo日志重放來實現(xiàn)。這樣，Xtrabackup備份出來的InnoDB數(shù)據(jù)文件雖然還是一致的，但是數(shù)據(jù)與binlog的位置可能不一致。那么當要用這個位置時可能會出錯，比如搭建從庫。

Xtrabackup在2.2.3版本中解決了這個問題，解決方法也很簡單，就是在"完成redo拷貝"前“同步redo到磁盤”。在上圖中可以看到，同步redo到磁盤的操作位置。

MySQL

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。