MySQL 自身的 mysqldump 工具支持單線程工作， 依次一個(gè)個(gè)導(dǎo)出多個(gè)表，沒有一個(gè)并行的機(jī) ，這就使得它無法迅速的備份數(shù)據(jù)。

mydumper 作為一個(gè)實(shí)用工具，能夠良好支持多線程工作， 可以并行的多線程的從表中讀入數(shù)據(jù)并同時(shí)寫到不同的文件里 ，這使得它在處理速度方面快于傳統(tǒng)的 mysqldump 。其特征之一是在處理過程中需要對列表加以鎖定，因此如果我們需要在工作時(shí)段執(zhí)行備份工作，那么會引起 DML 阻塞。但一般現(xiàn)在的 MySQL 都有主從，備份也大部分在從上進(jìn)行，所以鎖的問題可以不用考慮。這樣， mydumper 能更好的完成備份任務(wù)。

mydumper 特性

• 多線程備份
• 因?yàn)槭嵌嗑€程邏輯備份，備份后會生成多個(gè)備份文件
• 備份時(shí)對 MyISAM 表施加 FTWRL (FLUSH TABLES WITH READ LOCK), 會阻塞 DML 語句
• 保證備份數(shù)據(jù)的一致性
• 支持文件壓縮
• 支持導(dǎo)出binlog
• 支持多線程恢復(fù)
• 支持以守護(hù)進(jìn)程模式工作，定時(shí)快照和連續(xù)二進(jìn)制日志
• 支持將備份文件切塊

mydumper 備份機(jī)制

mydumper 工作流程圖

主要步驟概括

• 主線程 FLUSH TABLES WITH READ LOCK , 施加全局只讀鎖，以阻止 DML 語句寫入，保證數(shù)據(jù)的一致性
• 讀取當(dāng)前時(shí)間點(diǎn)的二進(jìn)制日志文件名和日志寫入的位置并記錄在 metadata 文件中，以供即使點(diǎn)恢復(fù)使用
• N 個(gè)（線程數(shù)可以指定，默認(rèn)是 4 ） dump 線程 START TRANSACTION WITH CONSISTENT SNAPSHOT ; 開啟讀一致的事物
• dump non-InnoDB tables , 首先導(dǎo)出非事物引擎的表
• 主線程 UNLOCK TABLES 非事物引擎?zhèn)浞萃旰螅尫湃种蛔x鎖
• dump InnoDB tables , 基于事物導(dǎo)出 InnoDB 表
• 事物結(jié)束
• 備份所生成的文件

所有的備份文件在一個(gè)目錄中，目錄可以自己指定
目錄中包含一個(gè) metadata 文件
記錄了備份數(shù)據(jù)庫在備份時(shí)間點(diǎn)的二進(jìn)制日志文件名，日志的寫入位置，

如果是在從庫進(jìn)行備份，還會記錄備份時(shí)同步至主庫的二進(jìn)制日志文件及寫入位置

每個(gè)表有兩個(gè)備份文件：

1. database.table-schema.sql 表結(jié)構(gòu)文件
2. database.table.sql 表數(shù)據(jù)文件

如果對表文件分片，將生成多個(gè)備份數(shù)據(jù)文件，可以指定行數(shù)或指定大小分片

安裝使用實(shí)例

假設(shè)現(xiàn)有2臺DB服務(wù)器，分別用于A業(yè)務(wù)與B業(yè)務(wù)，其中A業(yè)務(wù)比較重要，需要對A業(yè)務(wù)的1個(gè)DB（TaeOss）進(jìn)行熱備，大概有40G的數(shù)據(jù)，并用業(yè)務(wù)B的DB服務(wù)器作為備機(jī)，服務(wù)器分布如下：
10.137.143.151     A業(yè)務(wù)
10.137.143.152     B業(yè)務(wù)
 
假設(shè)要達(dá)到的要求是：
在導(dǎo)出A業(yè)務(wù)的DB（TaeOss）時(shí)，不能對A業(yè)務(wù)有影響。同時(shí)在B業(yè)務(wù)的DB服務(wù)器上進(jìn)行恢復(fù)時(shí)，也不能有較大影響，盡量控制在1分鐘以內(nèi)。
 
采取的方案：
1、mysqldump：屬于邏輯備份，會存在鎖表，但考慮到數(shù)據(jù)量比較大，鎖表的時(shí)間會比較長，業(yè)務(wù)不允許，pass掉；
2、xtrabackup：屬于物理備份，不存在鎖表，但考慮到2臺DB使用的都是共享表空間，同時(shí)在業(yè)務(wù)B的數(shù)據(jù)庫進(jìn)行恢復(fù)時(shí)，一是時(shí)間比較長，二是數(shù)據(jù)肯定不正確，pass掉（測試過）；
3、mydumper：屬于邏輯備份，是一個(gè)多線程、高性能的數(shù)據(jù)邏輯備份、恢復(fù)的工具，且鎖表的時(shí)間很短（40G數(shù)據(jù)，10分鐘以內(nèi)），同時(shí)會記錄binlog file和pos，業(yè)務(wù)可以接受。
 
mydumper主要有如下特性：
(1)、任務(wù)速度要比mysqldump快6倍以上；
(2)、事務(wù)性和非事務(wù)性表一致的快照（適用于0.2.2以上版本）；
(3)、快速的文件壓縮；
(4)、支持導(dǎo)出binlog；
(5)、多線程恢復(fù)（適用于0.2.1以上版本）；
(6)、以守護(hù)進(jìn)程的工作方式，定時(shí)快照和連續(xù)二進(jìn)制日志（適用于0.5.0以上版本）。
 
mydumper安裝：
https://launchpad.net/mydumper/0.6/0.6.2/+download/mydumper-0.6.2.tar.gz

# yum install glib2-devel mysql-devel zlib-devel pcre-devel
# tar zxvf mydumper-0.6.2.tar.gz
# cd mydumper-0.6.2
# cmake .
# make
# make install

 
參數(shù)如下：

由于DB是部署在比較老的SuSE Linux 10服務(wù)器上，安裝mydumper時(shí)依賴的庫比較多，會比較繁瑣，同時(shí)采用本地備份的話，也會占用大量的磁盤I/O，所以我們選擇在同網(wǎng)段的另一臺centos 6.4（10.137.143.156）服務(wù)器進(jìn)行備份。
 
步驟如下：
1、在“10.137.143.151、10.137.143.152”上對“10.137.143.156”進(jìn)行臨時(shí)授權(quán)

# mysql -uroot -e "grant all privileges on *.* to 'backup'@'10.137.143.156' identified by 'backup2015';"
# mysql -uroot -e "flush privileges;"

 
2、在“10.137.143.156”上對“10.137.143.151”的DB（TaeOss）進(jìn)行備份

# mydumper -h 10.137.143.151 -u backup -p backup2015 -B TaeOss -t 8 -o /data/rocketzhang

 
3、將備份數(shù)據(jù)恢復(fù)到“10.137.143.152”

# myloader -h 10.137.143.152 -u backup -p backup2015 -B TaeOss -t 8 -o -d /data/rocketzhang

 
4、主從關(guān)系建立：10.137.143.151（主）、10.137.143.152（從）
在“10.137.143.151”建立授權(quán)賬號：

# mysql -uroot -e "grant replication slave on *.* to 'repl'@'10.137.143.152' identified by 'repl123456';"
# mysql -uroot -e "flush privileges;"
 

在“10.137.143.156”查看記錄下的binlog信息：

在“10.137.143.152”如下操作：

# vim /etc/my.cnf
……
replicate-do-table = TaeOss.%
replicate-wild-do-table = TaeOss.%
……
 
# service mysqld reload
 
# mysql -uroot -e "change master to master_host='10.137.143.151',master_user='repl',master_password='repl123456',master_log_file='mysql-bin.002205',master_log_pos=456584891;"
# mysql -uroot -e "start slave;"
 
# mysql -uroot -e "show slave status\G;"

出現(xiàn)如下信息：

看來是存在主鍵沖突，導(dǎo)致主從復(fù)制失敗。
 
問題分析：
在主DB（10.137.143.151）上執(zhí)行：

# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.002205 > mysql-bin.002205.txt
# grep -C 8 529864938 mysql-bin.002205.txt

大概的意思是，在主DB上存在對t_evil_detect_uin_blacklist表的insert操作時(shí)，發(fā)生了主鍵沖突，當(dāng)在從端進(jìn)行同步的時(shí)候，也出現(xiàn)了主鍵沖突，從而導(dǎo)致主從同步失敗。
 
臨時(shí)的解決辦法：
導(dǎo)出從端的表TaeOss.t_evil_detect_uin_blacklist

# mysqldump -uroot --opt TaeOss t_evil_detect_uin_blacklist > TaeOss.t_evil_detect_uin_blacklist.sql

 
去掉TaeOss.t_evil_detect_uin_blacklist.sql其中的主鍵語句：

然后再導(dǎo)入：

# mysql -uroot TaeOss < TaeOss.t_evil_detect_uin_blacklist.sql
 
# mysql -uroot -e "stop slave;"
# mysql -uroot -e "start slave;"
# mysql -uroot -e "show slave status\G;"

最新評論