Mysql備份系列（2）--mysqldump備份（全量+增量）方案操做記錄

 

在平常運維工做中，對mysql數據庫的備份是萬分重要的，以防在數據庫表丟失或損壞狀況出現，能夠及時恢復數據。

線上數據庫備份場景：
每週日執行一次全量備份，而後天天下午1點執行MySQLdump增量備份.

下面對這種備份方案詳細說明下：
1.MySQLdump增量備份配置
執行增量備份的前提條件是MySQL打開binlog日誌功能，在my.cnf中加入
log-bin=/opt/Data/MySQL-bin
「log-bin=」後的字符串爲日誌記載目錄，通常建議放在不一樣於MySQL數據目錄的磁盤上。

-----------------------------------------------------------------------------------
mysqldump >       導出數據
mysql <           導入數據  （或者使用source命令導入數據，導入前要先切換到對應庫下）

注意一個細節：
如果mysqldump導出一個庫的數據，導出文件爲a.sql，而後mysql導入這個數據到新的空庫下。
若是新庫名和老庫名不一致，那麼須要將a.sql文件裏的老庫名改成新庫名，
這樣才能順利使用mysql命令導入數據（若是使用source命令導入就不須要修改a.sql文件了）。
-----------------------------------------------------------------------------------

2.MySQLdump增量備份
假定星期日下午1點執行全量備份，適用於MyISAM存儲引擎。
[root@test-huanqiu ~]# MySQLdump --lock-all-tables --flush-logs --master-data=2 -u root -p test > backup_sunday_1_PM.sql

對於InnoDB將--lock-all-tables替換爲--single-transaction
--flush-logs爲結束當前日誌，生成新日誌文件；
--master-data=2 選項將會在輸出SQL中記錄下徹底備份後新日誌文件的名稱，

用於往後恢復時參考，例如輸出的備份SQL文件中含有：
CHANGE MASTER TO MASTER_LOG_FILE=’MySQL-bin.000002′, MASTER_LOG_POS=106;

3.MySQLdump增量備份其餘說明：
若是MySQLdump加上–delete-master-logs 則清除之前的日誌，以釋放空間。可是若是服務器配置爲鏡像的複製主服務器，用MySQLdump –delete-master-logs刪掉MySQL二進制日誌很危險，由於從服務器可能尚未徹底處理該二進制日誌的內容。在這種狀況下，使用 PURGE MASTER LOGS更爲安全。

每日定時使用 MySQLadmin flush-logs來建立新日誌，並結束前一日誌寫入過程。並把前一日誌備份，例如上例中開始保存數據目錄下的日誌文件 MySQL-bin.000002 , ...

1.恢復徹底備份
mysql -u root -p < backup_sunday_1_PM.sql

2.恢復增量備份
mysqlbinlog MySQL-bin.000002 … | MySQL -u root -p注意這次恢復過程亦會寫入日誌文件，若是數據量很大，建議先關閉日誌功能

--compatible=name
它告訴 MySQLdump，導出的數據將和哪一種數據庫或哪一個舊版本的 MySQL 服務器相兼容。值能夠爲 ansi、MySQL32三、MySQL40、postgresql、oracle、mssql、db二、maxdb、no_key_options、no_tables_options、no_field_options 等，要使用幾個值，用逗號將它們隔開。固然了，它並不保證能徹底兼容，而是儘可能兼容。

--complete-insert，-c
導出的數據採用包含字段名的完整 INSERT 方式，也就是把全部的值都寫在一行。這麼作能提升插入效率，可是可能會受到 max_allowed_packet 參數的影響而致使插入失敗。所以，須要謹慎使用該參數，至少我不推薦。

--default-character-set=charset
指定導出數據時採用何種字符集，若是數據表不是採用默認的 latin1 字符集的話，那麼導出時必須指定該選項，不然再次導入數據後將產生亂碼問題。

--disable-keys
告訴 MySQLdump 在 INSERT 語句的開頭和結尾增長 /*!40000 ALTER TABLE table DISABLE KEYS */; 和 /*!40000 ALTER TABLE table ENABLE KEYS */; 語句，這能大大提升插入語句的速度，由於它是在插入完全部數據後才重建索引的。該選項只適合 MyISAM 表。

--extended-insert = true|false
默認狀況下，MySQLdump 開啓 --complete-insert 模式，所以不想用它的的話，就使用本選項，設定它的值爲 false 便可。

--hex-blob
使用十六進制格式導出二進制字符串字段。若是有二進制數據就必須使用本選項。影響到的字段類型有 BINARY、VARBINARY、BLOB。

--lock-all-tables，-x
在開始導出以前，提交請求鎖定全部數據庫中的全部表，以保證數據的一致性。這是一個全局讀鎖，而且自動關閉 --single-transaction 和 --lock-tables 選項。

--lock-tables
它和 --lock-all-tables 相似，不過是鎖定當前導出的數據表，而不是一會兒鎖定所有庫下的表。本選項只適用於 MyISAM 表，若是是 Innodb 表能夠用 --single-transaction 選項。

--no-create-info，-t
只導出數據，而不添加 CREATE TABLE 語句。

--no-data，-d
不導出任何數據，只導出數據庫表結構。
mysqldump --no-data --databases mydatabase1 mydatabase2 mydatabase3 > test.dump
將只備份表結構。--databases指示主機上要備份的數據庫。

--opt
這只是一個快捷選項，等同於同時添加 --add-drop-tables --add-locking --create-option --disable-keys --extended-insert --lock-tables --quick --set-charset 選項。本選項能讓 MySQLdump 很快的導出數據，而且導出的數據能很快導回。該選項默認開啓，但能夠用 --skip-opt 禁用。注意，若是運行 MySQLdump 沒有指定 --quick 或 --opt 選項，則會將整個結果集放在內存中。若是導出大數據庫的話可能會出現問題。

--quick，-q
該選項在導出大表時頗有用，它強制 MySQLdump 從服務器查詢取得記錄直接輸出而不是取得全部記錄後將它們緩存到內存中。

--routines，-R
導出存儲過程以及自定義函數。

--single-transaction
該選項在導出數據以前提交一個 BEGIN SQL語句，BEGIN 不會阻塞任何應用程序且能保證導出時數據庫的一致性狀態。它只適用於事務表，例如 InnoDB 和 BDB。本選項和 --lock-tables 選項是互斥的，由於 LOCK TABLES 會使任何掛起的事務隱含提交。要想導出大表的話，應結合使用 --quick 選項。

--triggers
同時導出觸發器。該選項默認啓用，用 --skip-triggers 禁用它。

跨主機備份
使用下面的命令能夠將host1上的sourceDb複製到host2的targetDb，前提是host2主機上已經建立targetDb數據庫：
-C 指示主機間的數據傳輸使用數據壓縮
mysqldump --host=host1 --opt sourceDb| mysql --host=host2 -C targetDb

結合Linux的cron命令實現定時備份
好比須要在天天凌晨1:30備份某個主機上的全部數據庫並壓縮dump文件爲gz格式
30 1 * * * mysqldump -u root -pPASSWORD --all-databases | gzip > /mnt/disk2/database_`date '+%m-%d-%Y'`.sql.gz

一個完整的Shell腳本備份MySQL數據庫示例。好比備份數據庫opspc
[root@test-huanqiu ~]# vim /root/backup.sh
#!bin/bash
echo "Begin backup mysql database"
mysqldump -u root -ppassword opspc > /home/backup/mysqlbackup-`date +%Y-%m-%d`.sql
echo "Your database backup successfully completed"

[root@test-huanqiu ~]# crontab -e
30 1 * * * /bin/bash -x /root/backup.sh > /dev/null 2>&1

mysqldump全量備份+mysqlbinlog二進制日誌增量備份
1）從mysqldump備份文件恢復數據會丟失掉從備份點開始的更新數據，因此還須要結合mysqlbinlog二進制日誌增量備份。
首先確保已開啓binlog日誌功能。在my.cnf中包含下面的配置以啓用二進制日誌：
[mysqld]
log-bin=mysql-bin

2）mysqldump命令必須帶上--flush-logs選項以生成新的二進制日誌文件：
mysqldump --single-transaction --flush-logs --master-data=2 > backup.sql
其中參數--master-data=[0|1|2]
0: 不記錄
1：記錄爲CHANGE MASTER語句
2：記錄爲註釋的CHANGE MASTER語句

mysqldump全量+增量備份方案的具體操做可參考下面兩篇文檔：
數據庫誤刪除後的數據恢復操做說明
解說mysql之binlog日誌以及利用binlog日誌恢復數據

--------------------------------------------------------------------------
下面分享一下本身用過的mysqldump全量和增量備份腳本

應用場景：
1）增量備份在週一到週六凌晨3點，會複製mysql-bin.00000*到指定目錄；
2）全量備份則使用mysqldump將全部的數據庫導出，每週日凌晨3點執行，並會刪除上週留下的mysq-bin.00000*，而後對mysql的備份操做會保留在bak.log文件中。

腳本實現：
1）全量備份腳本（假設mysql登陸密碼爲123456；注意腳本中的命令路徑）：
[root@test-huanqiu ~]# vim /root/Mysql-FullyBak.sh
#!/bin/bash
# Program
# use mysqldump to Fully backup mysql data per week!
# History
# Path
BakDir=/home/mysql/backup
LogFile=/home/mysql/backup/bak.log
Date=`date +%Y%m%d`
Begin=`date +"%Y年%m月%d日 %H:%M:%S"`
cd $BakDir
DumpFile=$Date.sql
GZDumpFile=$Date.sql.tgz
/usr/local/mysql/bin/mysqldump -uroot -p123456 --quick --events --all-databases --flush-logs --delete-master-logs --single-transaction > $DumpFile
/bin/tar -zvcf $GZDumpFile $DumpFile
/bin/rm $DumpFile
Last=`date +"%Y年%m月%d日 %H:%M:%S"`
echo 開始:$Begin 結束:$Last $GZDumpFile succ >> $LogFile
cd $BakDir/daily
/bin/rm -f *

2）增量備份腳本（腳本中mysql的數據存放路徑是/home/mysql/data，具體根據本身的實際狀況進行調整）
[root@test-huanqiu ~]# vim /root/Mysql-DailyBak.sh
#!/bin/bash
# Program
# use cp to backup mysql data everyday!
# History
# Path
BakDir=/home/mysql/backup/daily                     //增量備份時複製mysql-bin.00000*的目標目錄，提早手動建立這個目錄
BinDir=/home/mysql/data                                   //mysql的數據目錄
LogFile=/home/mysql/backup/bak.log
BinFile=/home/mysql/data/mysql-bin.index           //mysql的index文件路徑，放在數據目錄下的
/usr/local/mysql/bin/mysqladmin -uroot -p123456 flush-logs
#這個是用於產生新的mysql-bin.00000*文件
Counter=`wc -l $BinFile |awk '{print $1}'`
NextNum=0
#這個for循環用於比對$Counter,$NextNum這兩個值來肯定文件是否是存在或最新的
for file in `cat $BinFile`
do
    base=`basename $file`
    #basename用於截取mysql-bin.00000*文件名，去掉./mysql-bin.000005前面的./
    NextNum=`expr $NextNum + 1`
    if [ $NextNum -eq $Counter ]
    then
        echo $base skip! >> $LogFile
    else
        dest=$BakDir/$base
        if(test -e $dest)
        #test -e用於檢測目標文件是否存在，存在就寫exist!到$LogFile去
        then
            echo $base exist! >> $LogFile
        else
            cp $BinDir/$base $BakDir
            echo $base copying >> $LogFile
         fi
     fi
done
echo `date +"%Y年%m月%d日 %H:%M:%S"` $Next Bakup succ! >> $LogFile

3）設置crontab任務，執行備份腳本。先執行的是增量備份腳本，而後執行的是全量備份腳本：
[root@test-huanqiu ~]# crontab -e
#每一個星期日凌晨3:00執行徹底備份腳本
0 3 * * 0 /bin/bash -x /root/Mysql-FullyBak.sh >/dev/null 2>&1
#週一到週六凌晨3:00作增量備份
0 3 * * 1-6 /bin/bash -x /root/Mysql-DailyBak.sh >/dev/null 2>&1

4）手動執行上面兩個腳本，測試下備份效果
[root@test-huanqiu backup]# pwd
/home/mysql/backup
[root@test-huanqiu backup]# mkdir daily
[root@test-huanqiu backup]# ll
total 4
drwxr-xr-x. 2 root root 4096 Nov 29 11:29 daily
[root@test-huanqiu backup]# ll daily/
total 0

先執行增量備份腳本
[root@test-huanqiu backup]# sh /root/Mysql-DailyBak.sh
[root@test-huanqiu backup]# ll
total 8
-rw-r--r--. 1 root root 121 Nov 29 11:29 bak.log
drwxr-xr-x. 2 root root 4096 Nov 29 11:29 daily
[root@test-huanqiu backup]# ll daily/
total 8
-rw-r-----. 1 root root 152 Nov 29 11:29 mysql-binlog.000030
-rw-r-----. 1 root root 152 Nov 29 11:29 mysql-binlog.000031
[root@test-huanqiu backup]# cat bak.log
mysql-binlog.000030 copying
mysql-binlog.000031 copying
mysql-binlog.000032 skip!
2016年11月29日 11:29:32 Bakup succ!

而後執行全量備份腳本[root@test-huanqiu backup]# sh /root/Mysql-FullyBak.sh 20161129.sql[root@test-huanqiu backup]# lltotal 152-rw-r--r--. 1 root root 145742 Nov 29 11:30 20161129.sql.tgz-rw-r--r--. 1 root root 211 Nov 29 11:30 bak.logdrwxr-xr-x. 2 root root 4096 Nov 29 11:30 daily[root@test-huanqiu backup]# ll daily/total 0[root@test-huanqiu backup]# cat bak.log mysql-binlog.000030 copyingmysql-binlog.000031 copyingmysql-binlog.000032 skip!2016年11月29日 11:29:32 Bakup succ!開始:2016年11月29日 11:30:38 結束:2016年11月29日 11:30:38 20161129.sql.tgz succ