建站
咨詢
售后
建站咨詢
新聞中心
UPDATE or DELETE whitout where…
公司主營(yíng)業(yè)務(wù)：網(wǎng)站建設(shè)、成都做網(wǎng)站、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)建站是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。創(chuàng)新互聯(lián)建站推出青龍免費(fèi)做網(wǎng)站回饋大家。
table was DROPPed accidentally…
INNODB was corrupt…
entire datacenter loses power…
從數(shù)據(jù)安全的角度來(lái)說(shuō)，服務(wù)器磁盤(pán)都會(huì)做raid，MySQL本身也有主從、drbd等容災(zāi)機(jī)制，但它們都無(wú)法完全取代備份。容災(zāi)和高可用能幫我們 有效的應(yīng)對(duì)物理的、硬件的、機(jī)械的故障，而對(duì)我們犯下的邏輯錯(cuò)誤卻無(wú)能為力。每一種邏輯錯(cuò)誤發(fā)生的概率都極低，但是當(dāng)多種可能性疊加的時(shí)候，小概率事件就 放大成很大的安全隱患，這時(shí)候備份的必要性就凸顯了。那么在眾多的MySQL備份方式中，哪一種才是適合我們的呢？
常見(jiàn)的備份方式
MySQL本身為我們提供了mysqldump、mysqlbinlog遠(yuǎn)程備份工具，percona也為我們提供了強(qiáng)大的Xtrabackup， 加上開(kāi)源的mydumper，還有基于主從同步的延遲備份、從庫(kù)冷備等方式，以及基于文件系統(tǒng)快照的備份，其實(shí)選擇已經(jīng)多到眼花繚亂。而備份本身是為了恢 復(fù)，所以能夠讓我們?cè)诔霈F(xiàn)故障后迅速、準(zhǔn)確恢復(fù)的備份方式，就是最適合我們的，當(dāng)然，同時(shí)能夠省錢(qián)、省事，那就非常***。下面就我理解的幾種備份工具進(jìn)行 一些比較，探討下它們各自的適用場(chǎng)景。
1. mysqldump & mydumper
mysqldump是最簡(jiǎn)單的邏輯備份方式。在備份myisam表的時(shí)候，如果要得到一致的數(shù)據(jù)，就需要鎖表，簡(jiǎn)單而粗暴。而在備份innodb表 的時(shí)候，加上–master-data=1 –single-transaction 選項(xiàng)，在事務(wù)開(kāi)始時(shí)刻，記錄下binlog pos點(diǎn)，然后利用mvcc來(lái)獲取一致的數(shù)據(jù)，由于是一個(gè)長(zhǎng)事務(wù)，在寫(xiě)入和更新量很大的數(shù)據(jù)庫(kù)上，將產(chǎn)生非常多的undo，顯著影響性能，所以要慎用。
- 優(yōu)點(diǎn)：簡(jiǎn)單，可針對(duì)單表備份，在全量導(dǎo)出表結(jié)構(gòu)的時(shí)候尤其有用。
- 缺點(diǎn)：簡(jiǎn)單粗暴，單線程，備份慢而且恢復(fù)慢，跨IDC有可能遇到時(shí)區(qū)問(wèn)題。
- mydumper是mysqldump的加強(qiáng)版。相比mysqldump：
- 內(nèi)置支持壓縮，可以節(jié)省2-4倍的存儲(chǔ)空間。
- 支持并行備份和恢復(fù)，因此速度比mysqldump快很多，但是由于是邏輯備份，仍不是很快。
2. 基于文件系統(tǒng)的快照
基于文件系統(tǒng)的快照，是物理備份的一種。在備份前需要進(jìn)行一些復(fù)雜的設(shè)置，在備份開(kāi)始時(shí)刻獲得快照并記錄下binlog pos點(diǎn)，然后采用類似copy-on-write的方式，把快照進(jìn)行轉(zhuǎn)儲(chǔ)。轉(zhuǎn)儲(chǔ)快照本身會(huì)消耗一定的IO資源，而且在寫(xiě)入壓力較大的實(shí)例上，保存被更改 數(shù)據(jù)塊的前印象也會(huì)消耗IO，最終表現(xiàn)為整體性能的下降。而且服務(wù)器還要為copy-on-write快照預(yù)留較多的磁盤(pán)空間，這本身對(duì)資源也是一種浪 費(fèi)。因此這種備份方式我們使用的不多。
3. Xtrabackup
這或許是最為廣泛的備份方式。percona之所以家喻戶曉，Xtrabackup應(yīng)該功不可沒(méi)。它實(shí)際上是物理備份+邏輯備份的組合。在備份 innodb表的時(shí)候，它拷貝ibd文件，并一刻不停的監(jiān)視r(shí)edo log的變化，append到自己的事務(wù)日志文件。在拷貝ibd文件過(guò)程中，ibd文件本身可能被寫(xiě)”花”，這都不是問(wèn)題，因?yàn)樵诳截愅瓿珊蟮?**個(gè) prepare階段，Xtrabackup采用類似于innodb崩潰恢復(fù)的方法，把數(shù)據(jù)文件恢復(fù)到與日志文件一致的狀態(tài)，并把未提交的事務(wù)回滾。如果同 時(shí)需要備份myisam表以及innodb表結(jié)構(gòu)等文件，那么就需要用flush tables with lock來(lái)獲得全局鎖，開(kāi)始拷貝這些不再變化的文件，同時(shí)獲得binlog位置，拷貝結(jié)束后釋放鎖，也停止對(duì)redo log的監(jiān)視。
它的工作原理如下：
由于mysql中不可避免的含有myisam表，同時(shí)innobackup并不備份表結(jié)構(gòu)等文件，因此想要完整的備份mysql實(shí)例，就少不了要執(zhí)行 flush tables with read lock，而這個(gè)語(yǔ)句會(huì)被任何查詢(包括select)阻塞，在阻塞過(guò)程中，它又反過(guò)來(lái)阻塞任何查詢(包括select)。如果碰巧備份實(shí)例上有長(zhǎng)查詢先 于flush tables with read lock執(zhí)行，數(shù)據(jù)庫(kù)就會(huì)hang住。而當(dāng)flush tables with read lock獲得全局鎖后，雖然查詢可以執(zhí)行，但是仍會(huì)阻塞更新，所以，我們希望flush tables with read lock從發(fā)起到結(jié)束，持續(xù)的時(shí)間越短越好。
為了解決這個(gè)問(wèn)題，有兩種比較有效的方法：
- 1. 盡量不用myisam表。
- 2. Xtrabackup增加了–rsync選項(xiàng)，通過(guò)兩次rsync來(lái)減少持有全局鎖的時(shí)間。
優(yōu)化后的備份過(guò)程如下：
- 優(yōu)點(diǎn)：在線熱備，全備+增備+流備，支持限速，支持壓縮，支持加密。
- 缺點(diǎn)：需要獲取全局鎖，如果遇到長(zhǎng)查詢，等待時(shí)間將不可控，因此要做好監(jiān)控，必要時(shí)殺死長(zhǎng)查詢或自殺；遇到超大的實(shí)例，備份過(guò)程較長(zhǎng)，redo log太大會(huì)影響恢復(fù)速度，這種情況下***采用延遲備份。
4. mysqlbinlog 5.6
上述所有的備份方式，都只能把數(shù)據(jù)庫(kù)恢復(fù)到備份的某個(gè)時(shí)間點(diǎn)：mysqldump和mydumper，以及snapshot是備份開(kāi)始的時(shí)間 點(diǎn)；Xtrabackup是備份結(jié)束的時(shí)間點(diǎn)。要想實(shí)現(xiàn)point in time的恢復(fù)，還必須備份binlog。同時(shí)binlog也是實(shí)現(xiàn)增備的寶貴資源。
幸運(yùn)的是，mysql 5.6為我們提供了遠(yuǎn)程備份binlog的選項(xiàng)：
mysqlbinlog --raw --read-from-remote-server --stop-never
它會(huì)偽裝成mysql從庫(kù)，從遠(yuǎn)程獲取binlog然后進(jìn)行轉(zhuǎn)儲(chǔ)。這對(duì)線上主庫(kù)容量不夠無(wú)法保存較多binlog的場(chǎng)景非常有用。但是，它畢竟不像 真正的mysql從庫(kù)實(shí)例，狀態(tài)監(jiān)控和同步都需要單獨(dú)部署。因此個(gè)人覺(jué)得采用blackhole來(lái)備份全量的binlog是更好的選擇。筆者曾經(jīng)實(shí)現(xiàn)過(guò)一 個(gè)自動(dòng)搭建blackhole從庫(kù)的工具，稍加修改，就可以***搭建出blackhole從庫(kù)。一旦同步起來(lái)，基本一勞永逸，很少出問(wèn)題，主從切換的時(shí)候跟著切了就行。
提示：
- 不要小看binlog的備份。當(dāng)5.6的多線程復(fù)制大規(guī)模使用后，從庫(kù)追趕主庫(kù)命令點(diǎn)的耗時(shí)將被極大縮短，這樣我們把每天一次的全量備份改為每3 天一次、甚至每周一次的全量備份，和持續(xù)的binlog增量備份。遇到故障需要恢復(fù)數(shù)據(jù)的時(shí)候，重放3、5天的binlog也是極快的。降低備份頻率最直 接的好處是，省錢(qián)、省事。
- blackhole對(duì)于備份binlog是極好的。一方面可以長(zhǎng)久的備份binlog用于恢復(fù)數(shù)據(jù)庫(kù)，另一方面，在其上配置半同步復(fù)制，可以有效防止主庫(kù)的binlog丟失。
總結(jié)
備份方式各有千秋，而對(duì)我們來(lái)說(shuō)，面對(duì)數(shù)千實(shí)例，選擇合適的備份工具來(lái)實(shí)現(xiàn)統(tǒng)一配置、統(tǒng)一規(guī)劃，構(gòu)建智能調(diào)度的備份云平臺(tái)才是王道。畢竟，多種備份方式共存的運(yùn)維成本是不容忽視的。
從使用經(jīng)驗(yàn)來(lái)看，用Xtrabackup全備數(shù)據(jù)，用blackhole增備binlog，并定期對(duì)備份數(shù)據(jù)的有效性進(jìn)行驗(yàn)證，是當(dāng)下比較好的選擇。
新聞標(biāo)題：為MySQL選擇合適的備份方式
本文路徑：http://www.dlmjj.cn/article/cohhjch.html
