MySQL數(shù)據(jù)庫(kù)完整備份與增量備份的原理簡(jiǎn)介
MySQL數(shù)據(jù)庫(kù)實(shí)現(xiàn)備份的操作包括完整備份和增量備份等，本文我們主要介紹一下增量備份和完整備份的原理，接下來我們就一起來了解一下這部分內(nèi)容。
完整備份的原理：
對(duì)于InnoDB，XtraBackup基于InnoDB的crash-recovery功能進(jìn)行備份。
crash-recovery是這樣的：InnoDB維護(hù)了一個(gè)redo log，又稱為 transaction log，也叫事務(wù)日志，它包含了InnoDB數(shù)據(jù)的所有改動(dòng)情況。InnoDB啟動(dòng)的時(shí)候先去檢查datafile和transaction log，然后應(yīng)用所有已提交的事務(wù)并回滾所有未提交的事務(wù)。
XtraBackup在備份的時(shí)候并不鎖定表，而是一頁(yè)一頁(yè)地復(fù)制InnoDB的數(shù)據(jù)，與此同時(shí)，XtraBackup還有另外一個(gè)線程監(jiān)視著transactions log，一旦log發(fā)生變化，就把變化過的log pages復(fù)制走(因?yàn)閠ransactions log文件大小有限，寫滿之后，就會(huì)從頭再開始寫，新數(shù)據(jù)可能會(huì)覆蓋到舊的數(shù)據(jù)，所以一旦變化就要立刻復(fù)制走）。在全部數(shù)據(jù)文件復(fù)制完成之后，停止復(fù)制logfile。
XtraBackup采用了其內(nèi)置的InnoDB庫(kù)以read-write模式打開InnoDB的數(shù)據(jù)文件，然后每次讀寫1MB(1MB/16KB=64page)的數(shù)據(jù)，一頁(yè)一頁(yè)地遍歷，同時(shí)用InnoDB的buf_page_is_corrupted()函數(shù)檢查此頁(yè)的數(shù)據(jù)是否正常，如果正常則進(jìn)行復(fù)制，如不正常則重新讀取，最多重讀10次，如果還是失敗，則備份失敗退出。復(fù)制transactions log的原理也是一樣的，只不過每次讀寫512KB(512KB/16KB=32page)的數(shù)據(jù)。
由于XtraBackup其內(nèi)置的InnoDB庫(kù)打開文件的時(shí)候是rw的，所以運(yùn)行XtraBackup的用戶，必須對(duì)InnoDB的數(shù)據(jù)文件具有讀寫權(quán)限。
由于XtraBackup要從文件系統(tǒng)中復(fù)制大量的數(shù)據(jù)，所以它盡可能地使用posix_fadvise()，來告訴OS不要緩存讀取到的數(shù)據(jù)(因?yàn)檫@些數(shù)據(jù)不會(huì)重用到了)，從而提升性能。如果要緩存的話，大量的數(shù)據(jù)會(huì)對(duì)OS的虛擬內(nèi)存造成很大的壓力，其它進(jìn)程（如mysqld）很有可能會(huì)被swap出去，這樣就出問題了。同時(shí)，XtraBackup在讀取數(shù)據(jù)的時(shí)候還盡可能地預(yù)讀。
由于不鎖表，所以復(fù)制出來的數(shù)據(jù)是不一致的，數(shù)據(jù)的一致性是在恢復(fù)的時(shí)候使用crash-recovery進(jìn)行實(shí)現(xiàn)的。
對(duì)于MyISAM,XtraBackup還是首先鎖定所有的表，然后復(fù)制所有文件。
增量備份的原理：
在完整備份和增量備份文件中都有一個(gè)文件xtrabackup_checkpoints會(huì)記錄備份完成時(shí)檢查點(diǎn)的LSN。在進(jìn)行新的增量備份時(shí)，XtraBackup會(huì)比較表空間中每頁(yè)的LSN是否大于上次備份完成的LSN，如果是，則備份該頁(yè)，并記錄當(dāng)前檢查點(diǎn)的LSN。
以上就是MySQL數(shù)據(jù)庫(kù)完整備份和增量備份的原理的介紹，本文就介紹這里了，希望本次的介紹能夠?qū)δ兴斋@！
【編輯推薦】
分享到微信 
分享到微博
