Facebook中怎么做MySQL備份

Facebook中怎么做MySQL備份，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

　　Facebook是怎么做MySQL備份的

　　從mysqldump到Xtrabackup

　　我們使用mysqldump來(lái)進(jìn)行每日的數(shù)據(jù)庫(kù)備份,mysqldump對(duì)數(shù)據(jù)進(jìn)行邏輯備份,就像應(yīng)用訪問(wèn)數(shù)據(jù)庫(kù)那樣,mysqldump以SQL語(yǔ)句的方式從數(shù)據(jù)庫(kù)中讀取一張張表,將表結(jié)構(gòu)和數(shù)據(jù)轉(zhuǎn)保存到文該篇文章件.mysqldump最大的問(wèn)題是速度太慢(對(duì)于我們的一些大的數(shù)據(jù)庫(kù),通常要花24小時(shí),甚至更久),并且以SQL語(yǔ)句的方式讀取數(shù)據(jù)可能造成磁盤(pán)的隨機(jī)讀,這就會(huì)造成主機(jī)的load增大,影響性能.對(duì)于時(shí)間太長(zhǎng),我們可以跑多個(gè)實(shí)例來(lái)并發(fā)的做備份,這能縮短備份的時(shí)間,但是會(huì)造成更多的load,更影響主機(jī)的性能.

　　另外一個(gè)可行的備份方式是進(jìn)行物理備份(我們稱(chēng)之為二進(jìn)制備份,binarybackup),通過(guò)操作系統(tǒng)層面,讀取數(shù)據(jù)庫(kù)磁盤(pán)文件,而非通過(guò)SQL語(yǔ)句.這樣的話(huà)在備份的過(guò)程中,數(shù)據(jù)不能像SQL讀取的時(shí)候保持事務(wù)上一致的.只有當(dāng)備份的數(shù)據(jù)文件在數(shù)據(jù)庫(kù)里復(fù)原了,他們才又一致了,這類(lèi)似于數(shù)據(jù)庫(kù)down掉之重啟一樣.

　　我們通過(guò)修改增強(qiáng)Xtrabackup來(lái)滿(mǎn)足我們額外的需求:

　　1.支持快速的表級(jí)還原

　　2.增強(qiáng)全量和增量備份

　　3.支持混合增量備份

　　Xtrabackup支持增量備份,也就是備份自上次全量備份后改變的數(shù)據(jù).這樣我們就能夠減少備份的空間(比如每天一次增量備份,每周一次全量備份).Xtrabackup也支持多級(jí)增量備份,不過(guò)我們不使用,避免復(fù)雜.

　　Facebook是怎么做MySQL備份的

　　1.表級(jí)還原

　　我們寫(xiě)了一個(gè)PHP腳本,來(lái)從二進(jìn)制備份文件中讀取并還原指定的表.當(dāng)前,這個(gè)腳本還不能自己從備份文件中讀取信息創(chuàng)建表結(jié)構(gòu),因此必須事先準(zhǔn)備好一個(gè)對(duì)應(yīng)的空的表.我們對(duì)Xtrabackup也做了相應(yīng)的修改來(lái)支持這個(gè)工具.這個(gè)修改就是支持Xtrabackup導(dǎo)入導(dǎo)出單表.單表的還原比全量還原快得多,因?yàn)橹恍枰獜奈募凶x取相應(yīng)的表的信息.

　　2.調(diào)整全量和增量復(fù)制

　　fb是Xtrabackup早期的增量備份功能的用戶(hù),起初對(duì)于一些有大量表的數(shù)據(jù)庫(kù)，Xtrabackup的增量備份不起作用.后來(lái)我們和percona一起解決了這些問(wèn)題.

　　Xtrabackup只有本地增量備份功能,也就是說(shuō)增量備份的文件必須要和MySQL在同臺(tái)主機(jī)上.我們修改使之支持遠(yuǎn)程增量備份,也就是通過(guò)類(lèi)似管道的方式將備份的數(shù)據(jù)同時(shí)發(fā)送到遠(yuǎn)程主機(jī),.如果先在本地做增量備份,然后通過(guò)網(wǎng)絡(luò)傳到遠(yuǎn)程主機(jī),對(duì)我們來(lái)說(shuō)是不可取的,因?yàn)闀?huì)大大增加本地的寫(xiě)操作.

　　Xtrabackup以1MB為1個(gè)chunk來(lái)讀取數(shù)據(jù)庫(kù)文件,我們發(fā)現(xiàn)使用8MB時(shí),能夠使增量備份的速度快一倍,使全量備份快40%.

　　3.讓增量備份成為真正的增量

　　Xtrabackup的增量備份讀取數(shù)據(jù)庫(kù)的每個(gè)page,來(lái)判斷哪些page改變了.我們創(chuàng)建了一個(gè)page追蹤器,通過(guò)讀取事務(wù)日志,并且通過(guò)每個(gè)表的bitmap,來(lái)追蹤修改過(guò)的page,.這樣我們就能很好的追蹤哪些page改變了哪些沒(méi)變,我們就可以只讀取那些改變過(guò)的page.我們稱(chēng)這位真正的增量備份.

　　不過(guò)諷刺的是,我們發(fā)現(xiàn)這種真正的增量備份比普通的增量備份反而來(lái)的慢..這是因?yàn)槠胀ǖ脑隽總浞萦?MB的chunk來(lái)讀取文件,而真正的增量備份讀取文件的大小是不定的,從16KB(INNODB中一個(gè)page的大小)到8MB,這取決于有多少連續(xù)的page是被修改過(guò)的.因此在我們的很多場(chǎng)景下(自上次全量備份后大概10%-30%的page修改了),真正的增量備份比普通的增量備份花了更多的IO調(diào)用.

　　因?yàn)槲覀冞M(jìn)行了改進(jìn),有了一種混合增量的備份，通過(guò)避免讀取未修改的page來(lái)減少I(mǎi)O次數(shù),在我們的場(chǎng)景下,這種混合增量備份減少了20%-30%的IO,IO的大小從16KB到8MB不等.

　　下表描述了使用上述改進(jìn)的方法來(lái)處理大概750GB數(shù)據(jù)時(shí)產(chǎn)生的不同結(jié)果.由于mysqldump速度的原因,mysqldump只在少數(shù)幾個(gè)數(shù)據(jù)庫(kù)上跑,我們使用gzip來(lái)對(duì)mysqldump的結(jié)果進(jìn)行壓縮,很慢,但是壓縮率很高.

　　QPress用來(lái)壓縮二進(jìn)制備份,它比gzip快多了,但是壓縮效率更低.由于我們經(jīng)常作增量備份,較少作全量備份,整個(gè)二進(jìn)制備份所需要的空間和mysqldump所需要的空間還是差不多的。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。