MySQL數(shù)據(jù)庫實現(xiàn)備份的操作包括完整備份和增量備份等，本文我們主要介紹一下增量備份和完整備份的原理，接下來我們就一起來了解一下這部分內(nèi)容。

完整備份的原理：

對于InnoDB，XtraBackup基于InnoDB的crash-recovery功能進行備份。

crash-recovery是這樣的：InnoDB維護了一個redo log，又稱為 transaction log，也叫事務日志，它包含了InnoDB數(shù)據(jù)的所有改動情況。InnoDB啟動的時候先去檢查datafile和transaction log，然后應用所有已提交的事務并回滾所有未提交的事務。

XtraBackup在備份的時候并不鎖定表，而是一頁一頁地復制InnoDB的數(shù)據(jù)，與此同時，XtraBackup還有另外一個線程監(jiān)視著transactions log，一旦log發(fā)生變化，就把變化過的log pages復制走(因為transactions log文件大小有限，寫滿之后，就會從頭再開始寫，新數(shù)據(jù)可能會覆蓋到舊的數(shù)據(jù)，所以一旦變化就要立刻復制走）。在全部數(shù)據(jù)文件復制完成之后，停止復制logfile。

XtraBackup采用了其內(nèi)置的InnoDB庫以read-write模式打開InnoDB的數(shù)據(jù)文件，然后每次讀寫1MB(1MB/16KB=64page)的數(shù)據(jù)，一頁一頁地遍歷，同時用InnoDB的buf_page_is_corrupted()函數(shù)檢查此頁的數(shù)據(jù)是否正常，如果正常則進行復制，如不正常則重新讀取，最多重讀10次，如果還是失敗，則備份失敗退出。復制transactions log的原理也是一樣的，只不過每次讀寫512KB(512KB/16KB=32page)的數(shù)據(jù)。

由于XtraBackup其內(nèi)置的InnoDB庫打開文件的時候是rw的，所以運行XtraBackup的用戶，必須對InnoDB的數(shù)據(jù)文件具有讀寫權(quán)限。

由于XtraBackup要從文件系統(tǒng)中復制大量的數(shù)據(jù)，所以它盡可能地使用posix_fadvise()，來告訴OS不要緩存讀取到的數(shù)據(jù)(因為這些數(shù)據(jù)不會重用到了)，從而提升性能。如果要緩存的話，大量的數(shù)據(jù)會對OS的虛擬內(nèi)存造成很大的壓力，其它進程（如mysqld）很有可能會被swap出去，這樣就出問題了。同時，XtraBackup在讀取數(shù)據(jù)的時候還盡可能地預讀。

由于不鎖表，所以復制出來的數(shù)據(jù)是不一致的，數(shù)據(jù)的一致性是在恢復的時候使用crash-recovery進行實現(xiàn)的。

對于MyISAM,XtraBackup還是首先鎖定所有的表，然后復制所有文件。

增量備份的原理：

在完整備份和增量備份文件中都有一個文件xtrabackup_checkpoints會記錄備份完成時檢查點的LSN。在進行新的增量備份時，XtraBackup會比較表空間中每頁的LSN是否大于上次備份完成的LSN，如果是，則備份該頁，并記錄當前檢查點的LSN。

以上就是MySQL數(shù)據(jù)庫完整備份和增量備份的原理的介紹，本文就介紹這里了，希望本次的介紹能夠?qū)δ兴斋@！

【編輯推薦】

1. MySQL數(shù)據(jù)庫中varchar的限制規(guī)則
2. MySQL數(shù)據(jù)庫負荷較高時的原因排查思路
3. MySQL簡單操作之a(chǎn)lter table改變表的結(jié)構(gòu)
4. MySQL簡單操作之用select查詢表中的記錄
5. MySQL數(shù)據(jù)庫主從服務器文檔的部署與切換詳解