qileilove

          blog已經(jīng)轉(zhuǎn)移至github,大家請訪問 http://qaseven.github.io/

          為MySQL選擇合適的備份方式

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

          posted on 2014-10-30 11:58 順其自然EVO 閱讀(374) 評論(0)  編輯  收藏 所屬分類: 測試學(xué)習(xí)專欄數(shù)據(jù)庫

          <2014年10月>
          2829301234
          567891011
          12131415161718
          19202122232425
          2627282930311
          2345678

          導(dǎo)航

          統(tǒng)計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 潢川县| 西平县| 泸州市| 新巴尔虎左旗| 桃园市| 灵寿县| 金堂县| 木兰县| 高雄县| 清徐县| 蕉岭县| 台北市| 柳林县| 太和县| 郁南县| 民勤县| 德格县| 牟定县| 八宿县| 浦县| 长武县| 青铜峡市| 赞皇县| 昆明市| 庆元县| 云霄县| 沭阳县| 抚宁县| 正安县| 鄱阳县| 松桃| 六枝特区| 云和县| 甘德县| 临朐县| 基隆市| 扎兰屯市| 新龙县| 娱乐| 邯郸市| 汤阴县|