應用mysqldump對MySQL的數據停止備份的操作教程。本站提示廣大學習愛好者：（應用mysqldump對MySQL的數據停止備份的操作教程）文章只能為提供參考，不一定能成為您想要的結果。以下是應用mysqldump對MySQL的數據停止備份的操作教程正文
MySQL 本身的 mysqldump 對象支撐單線程任務， 順次一個個導出多個表，沒有一個並行的機 ，這就使得它沒法敏捷的備份數據。
mydumper 作為一個適用對象，可以或許優越支撐多線程任務， 可以並行的多線程的從表中讀入數據並同時寫到分歧的文件裡 ，這使得它在處置速度方面快於傳統的 mysqldump 。其特點之一是在處置進程中須要對列表加以鎖定，是以假如我們須要在任務時段履行備份任務，那末會惹起 DML 壅塞。但普通如今的 MySQL 都有主從，備份也年夜部門在從長進行，所以鎖的成績可以不消斟酌。如許， mydumper 能更好的完成備份義務。
mydumper 特征
mydumper 備份機制
mydumper 任務流程圖
重要步調歸納綜合
一切的備份文件在一個目次中，目次可以本身指定
目次中包括一個 metadata 文件
記載了備份數據庫在備份時光點的二進制日記文件名，日記的寫入地位，
假如是在從庫停止備份，還會記載備份時同步至主庫的二進制日記文件及寫入地位
每一個表有兩個備份文件：
假如對表文件分片，將生成多個備份數據文件，可以指定行數或指定年夜小分片
裝置應用實例
假定現有2台DB辦事器，分離用於A營業與B營業，個中A營業比擬主要，須要對A營業的1個DB（TaeOss）停止熱備，年夜概有40G的數據，並用營業B的DB辦事器作為備機，辦事器散布以下：
10.137.143.151 A營業
10.137.143.152 B營業
假定要到達的請求是：
在導出A營業的DB（TaeOss）時，不克不及對A營業有影響。同時在B營業的DB辦事器長進行恢復時，也不克不及有較年夜影響，盡可能掌握在1分鐘之內。
采用的計劃：
1、mysqldump：屬於邏輯備份，會存在鎖表，但斟酌到數據量比擬年夜，鎖表的時光會比擬長，營業不許可，pass失落；
2、xtrabackup：屬於物理備份，不存在鎖表，但斟酌到2台DB應用的都是同享表空間，同時在營業B的數據庫停止恢復時，一是時光比擬長，二是數據確定不准確，pass失落（測試過）；
3、mydumper：屬於邏輯備份，是一個多線程、高機能的數據邏輯備份、恢復的對象，且鎖表的時光很短（40G數據，10分鐘之內），同時會記載binlog file和pos，營業可以接收。
mydumper重要有以下特征：
(1)、義務速度要比mysqldump快6倍以上；
(2)、事務性和非事務性表分歧的快照（實用於0.2.2以上版本）；
(3)、疾速的文件緊縮；
(4)、支撐導出binlog；
(5)、多線程恢復（實用於0.2.1以上版本）；
(6)、以守護過程的任務方法，准時快照和持續二進制日記（實用於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
參數以下：
因為DB是安排在比擬老的SuSE Linux 10辦事器上，裝置mydumper時依附的庫比擬多，會比擬繁瑣，同時采取當地備份的話，也會占用年夜量的磁盤I/O，所以我們選擇在同網段的另外一台centos 6.4（10.137.143.156）辦事器停止備份。
步調以下：
1、在“10.137.143.151、10.137.143.152”上對“10.137.143.156”停止暫時受權
# 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）停止備份
# mydumper -h 10.137.143.151 -u backup -p backup2015 -B TaeOss -t 8 -o /data/rocketzhang
3、將備份數據恢復到“10.137.143.152”
# myloader -h 10.137.143.152 -u backup -p backup2015 -B TaeOss -t 8 -o -d /data/rocketzhang
4、主從關系樹立：10.137.143.151（主）、10.137.143.152（從）
在“10.137.143.151”樹立受權賬號：
# 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;"
湧現以下信息：
看來是存在主鍵抵觸，招致主從復制掉敗。
成績剖析：
在主DB（10.137.143.151）上履行：
# 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操作時，產生了主鍵抵觸，當在從端停止同步的時刻，也湧現了主鍵抵觸，從而招致主從同步掉敗。
暫時的處理方法：
導出從真個表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個中的主鍵語句：
然後再導入：
# 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;"
