Mysql 備份恢復與xtrabackup備份
🎉新年賀詞🎉
2017年即將過去，新年的鐘聲即將敲響。在這辭舊迎新的美好時刻，我向全國各族人民，向香港特別行政區同胞、澳門特別行政區同胞，向臺灣同胞和海外僑胞，向工做在一線的運維工程師們，向爲開源事業作出貢獻的朋友們，向世界各國各地區的朋友們，致以新年的祝福！html
今天是2017的最後一天，在這樣一個特殊的日子裏，但願你們都能事事順心，快樂常在，但願在2018年裏都能有所成就，創造不同的價值。mysql
讓咱們滿懷信心和期待，一塊兒迎接新年的鐘聲！正則表達式
謝謝你們。算法
1.1 備份的緣由
備份是數據安全的最後一道防線，對於任何數據丟失的場景，備份雖然不必定能恢復百分之百的數據(取決於備份週期)，但至少能將損失降到最低。衡量備份恢復有兩個重要的指標：恢復點目標(RPO)和恢復時間目標(RTO)，前者重點關注能恢復到什麼程度，然後者則重點關注恢復須要多長時間。sql
1.1.1 備份的目錄
作災難恢復：對損壞的數據進行恢復和還原shell
需求改變：因需求改變而須要把數據還原到改變之前數據庫
測試：測試新功能是否可用安全
1.1.2 備份中須要考慮的問題
能夠容忍丟失多長時間的數據；服務器
恢復數據要在多長時間內完；多線程
恢復的時候是否須要持續提供服務；
恢復的對象，是整個庫，多個表，仍是單個庫，單個表。
1.1.3 備份的類型
熱備份：
這些動態備份在讀取或修改數據的過程當中進行，不多中斷或者不中斷傳輸或處理數據的功能。使用熱備份時，系統仍可供讀取和修改數據的操做訪問。
冷備份：
這些備份在用戶不能訪問數據時進行，所以沒法讀取或修改數據。這些脫機備份會阻止執行任何使用數據的活動。這些類型的備份不會干擾正常運行的系統的性能。可是，對於某些應用程序，會沒法接受必須在一段較長的時間裏鎖定或徹底阻止用戶訪問數據。
溫備份：
這些備份在讀取數據時進行，但在多數狀況下，在進行備份時不能修改數據自己。這種中途備份類型的優勢是沒必要徹底鎖定最終用戶。可是，其不足之處在於沒法在進行備份時修改數據集，這可能使這種類型的備份不適用於某些應用程序。在備份過程當中沒法修改數據可能產生性能問題。
1.2 備份的方式
1.2.1 冷備份
最簡單的備份方式就是，關閉MySQL服務器，而後將data目錄下面的全部文件進行拷貝保存，須要恢復時，則將目錄拷貝到須要恢復的機器便可。這種方式確實方便，可是在生產環境中基本沒什麼做用。由於全部的機器都是要提供服務的，即便是Slave有時候也須要提供只讀服務，因此關閉MySQL停服備份是不現實的。與冷備份相對應的一個概念是熱備份，所謂熱備份是在不影響MySQL對外服務的狀況下，進行備份。
冷備份及中止業務進行備份。
1.2.2 快照備份
首先要介紹的熱備份是快照備份，快照備份是指經過文件系統支持的快照功能對數據庫進行備份。備份的原理是將全部的數據庫文件放在同一分區中，而後對該分區執行快照工做，對於Linux而言，須要經過LVM(Logical Volumn Manager)來實現。LVM使用寫時複製(copy-on-write)技術來建立快照，例如，對整個卷的某個瞬間的邏輯副本，相似於數據庫中的innodb存儲引擎的MVCC，只不過LVM的快照在文件系統層面，而MVCC在數據庫層面，並且僅支持innodb存儲引擎。
LVM有一個快照預留區域，若是原始卷數據有變化時，LVM保證在任何變動寫入以前，會複製受影響塊到快照預留區域。簡單來講，快照區域內保留了快照點開始時的一致的全部old數據。對於更新不多的數據庫，快照也會很是小。
對於MySQL而言，爲了使用快照備份，須要將數據文件，日誌文件都放在一個邏輯卷中，而後對該卷快照備份便可。因爲快照備份，只能本地，所以，若是本地的磁盤損壞，則快照也就損壞了。快照備份更偏向於對誤操做防範，能夠將數據庫迅速恢復到快照產生的時間點，而後結合二進制日誌能夠恢復到指定的時間點。基本原理以下圖：
1.2.3 邏輯備份（文本表示：SQL 語句）
冷備份和快照備份因爲其弊端在生產環境中不多使用，使用更可能是MySQL自帶的邏輯備份和物理備份工具，這節主要講邏輯備份，MySQL官方提供了Mysqldump邏輯備份工具，雖然已經足夠好，但存在單線程備份慢的問題。在社區提供了更優秀的邏輯備份工具mydumper，它的優點主要體如今多線程備份，備份速度更快。
1.2.4 其餘經常使用的備份方式
物理備份（數據文件的二進制副本）
全量備份概念
全量數據就是數據庫中全部的數據（或某一個庫的所有數據）；
全量備份就是把數據庫中全部的數據進行備份。
mysqldump會取得一個時刻的一致性數據.
增量備份（刷新二進制日誌）
增量數據就是指上一次全量備份數據以後到下一次全備以前數據庫所更新的數據
對於mysqldump,binlog就是增量數據.
1.2.5 備份工具的介紹
一、mysqldump: mysql原生自帶很好用的邏輯備份工具
二、mysqlbinlog: 實現binlog備份的原生態命令
三、xtrabackup: precona公司開發的性能很高的物理備份工具
1.3 mysqldump備份介紹
備份的基本流程以下：
1.調用FTWRL(flush tables with read lock)，全局禁止讀寫 2.開啓快照讀，獲取此時的快照(僅對innodb表起做用) 3.備份非innodb表數據(*.frm,*.myi,*.myd等) 4.非innodb表備份完畢後，釋放FTWRL鎖 5.逐一備份innodb表數據 6.備份完成。
整個過程，能夠參考我同事的一張圖，但他的這張圖只考慮innodb表的備份狀況，實際上在unlock tables執行完畢以前，非innodb表已經備份完畢，後面的t1,t2和t3實質都是innodb表，並且5.6的mysqldump利用保存點機制，每備份完一個表就將一個表上的MDL鎖釋放，避免對一張表鎖更長的時間。
1.3.1 mysqldump備份流程
1.3.2 經常使用的備份參數
| 參數 |
參數說明 |
| -A |
備份全庫 |
| -B |
備某一個數據庫下的全部表 |
| -R, --routines |
備份存儲過程和函數數據 |
| --triggers |
備份觸發器數據 |
| --master-data={1|2} |
告訴你備份後時刻的binlog位置 若是等於1，則將其打印爲CHANGE MASTER命令; 若是等於2，那麼該命令將以註釋符號爲前綴。 |
| --single-transaction |
對innodb引擎進行熱備 |
| -F, --flush-logs |
刷新binlog日誌 |
| -x, --lock-all-tables |
鎖定全部數據庫的全部表。這是經過在整個轉儲期間採用全局讀鎖來實現的。 |
| -l, --lock-tables |
鎖定全部表以供讀取 |
| -d |
僅表結構 |
| -t |
僅數據 |
| --compact |
減小無用數據輸出(調試) |
| 一個完整的備份語句： innodb引擎的備份命令以下： mysqldump -A -R --triggers --master-data=2 --single-transaction |gzip >/opt/all_$(date +%F).sql.gz 適合多引擎混合（例如：myisam與innodb混合）的備份命令以下：
mysqldump -A -R --triggers --master-data=2 |gzip >/opt/all_$(date +%F).sql.gz |
|
1.3.3 -A 參數
備份全庫，備份語句
mysqldump -uroot -p123 -A > /backup/full.sql
1.3.4 -B 參數
備某一個數據庫下的全部表
增長建庫（create）及「use庫」的語句，能夠直接接多個庫名，同時備份多個庫* -B 庫1 庫2
mysqldump -uroot -p123 -B world > /backup/worldb.sql
備份語句：
create database if not 存在 use db1 drop table create table insert into
不加-B備份數據庫時，只是備份數據庫下的全部表，不會建立數據庫
只能備份單獨的數據庫（通常用於備份單表時使用）
mysqldump -uroot -p123 world > /backup/world.sql
備份單表
mysqldump -uroot -p123 world city > /backup/world_city.sql
對於單表備份的粒度，再恢復數據庫數據時速度最快。
備份多個表
mysqldump 庫1 表1 表2 表3 >庫1.sql mysqldump 庫2 表1 表2 表3 >庫2.sql
分庫備份:for循環
mysqldump -uroot -p'mysql123' -B mysql ... mysqldump -uroot -p'mysql123' -B mysql_utf8 ... mysqldump -uroot -p'mysql123' -B mysql ... ......
分庫備份
for name in `mysql -e "show databases;"|sed 1d` do mysqldump -uroot -p'mysql123' -B $name done
1.3.5 --master-data={1|2}參數
告訴你備份後時刻的binlog位置
2爲註釋 1爲非註釋，要執行的(主從複製)
[root@db02 logs]# sed -n '22p' /opt/t.sql CHANGE MASTER TO MASTER_LOG_FILE='clsn-bin.000005', MASTER_LOG_POS=344; [root@db02 logs]# mysqldump -B --master-data=2 clsn >/opt/t.sql
1.3.6 --single-transaction 參數
對innodb引擎進行熱備
只支持innodb引擎
使用該參數會單獨開啓一個事務進行備份，利用事務的快照技術實現。
基於事務引擎:不用鎖表就能夠得到一致性的備份.
體現了ACID四大特性中的隔離性，生產中99% 使用innodb事務引擎.
雖然支持熱備，並不意味着你能夠再任意時間點進行備份，特別是業務繁忙期，不要作備份策略，通常夜裏進行備份。
innodb引擎的備份命令以下：
mysqldump -A -B -R --triggers --master-data=2 --single-transaction |gzip >/opt/all.sql.gz
1.3.7 --flush-logs參數/-F
刷新binlog日誌
天天晚上0點備份數據庫
mysqldump -A -B -F >/opt/$(date +%F).sql
[root@db02 ~]# ll /application/mysql/logs/ -rw-rw---- 1 mysql mysql 168 Jun 21 12:06 clsn-bin.000001 -rw-rw---- 1 mysql mysql 168 Jun 21 12:06 clsn-bin.000002 -rw-rw---- 1 mysql mysql 210 Jun 21 12:07 clsn-bin.index
提示:每一個庫都會刷新一次.
1.3.8 壓縮備份
壓縮備份命令:
mysqldump -B --master-data=2 clsn|gzip >/opt/t.sql.gz
解壓:
zcat t.sql.gz >t1.sql gzip -d t.sql.gz #刪壓縮包 gunzip alL_2017-12-22.sql.gz
一個完整的備份語句
innodb引擎的備份命令以下：
mysqldump -A -R --triggers --master-data=2 --single-transaction |gzip >/opt/all.sql.gz
適合多引擎混合（例如：myisam與innodb混合）的備份命令以下：
mysqldump -A -R --triggers --master-data=2 |gzip >/opt/alL_$(date +%F).sql.gz
1.3.9 使用Mysqldump備份進行恢復實踐
備份innodb引擎數據庫clsn並壓縮：
mysqldump -B -R --triggers --master-data=2 clsn|gzip >/opt/all_$(date +%F).sql.gz
人爲刪除clsn數據庫：
[root@db02 opt]# mysql -e 「drop database clsn;」 [root@db02 opt]# mysql -e 「show databases;」
恢復數據庫：
使用gzip解壓 gzip -d xxx.gz shell> mysql </opt/all_2017-1222.sql 或 mysql> set sql_log_bin=0; Query OK, 0 rows affected (0.00 sec) mysql> source /backup/alL_2017-12-22.sql
驗證數據：
[root@db02 opt]# mysql -e 「use clsn;select * from test;」
1.4 【模擬】增量恢復企業案例
1.4.1 前提條件:
1.具有全量備份（mysqldump）。
2.除全量備份之外，還有全量備份以後產生的的全部binlog增量日誌。
1.4.2 環境準備
(1)準備環境：
drop database clsn; CREATE DATABASE clsn; USE `clsn`; CREATE TABLE `test` ( `id` int(4) NOT NULL AUTO_INCREMENT, `name` char(20) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8; INSERT INTO `test` VALUES (1,'clsn'),(2,'znix'),(3,'inca'),(4,'zuma'),(5,'kaka');
查看建立好的數據
mysql> select * from test; +----+------+ | id | name | +----+------+ | 1 | clsn | | 2 | znix | | 3 | inca | | 4 | zuma | | 5 | kaka | +----+------+ 5 rows in set (0.00 sec)
(2)模擬環境：
mkdir /data/backup -p date -s "2017/12/22"
全備份:
mysqldump -B --master-data=2 --single-transaction clsn|gzip>/data/backup/clsn_$(date +%F).sql.gz
模擬增量:
mysql -e "use clsn;insert into test values(6,'haha');" mysql -e "use clsn;insert into test values(7,'hehe');" mysql -e "select * from clsn.test;"
(3)模擬誤刪數據：
date -s "2017/12/22 11:40" mysql -e "drop database clsn;show databases;"
出現問題10分鐘後,發現問題,刪除了數據庫了.
1.4.3 恢復數據準備
(1)採用iptables防火牆屏蔽全部應用程序的寫入。
[root@clsn ~]# iptables -I INPUT -p tcp --dport 3306 ! -s 172.16.1.51 -j DROP #<==非172.16.1.51禁止訪問數據庫3306端口。
或採用mysql 配置參數，可是須要重啓數據庫
--skip-networking
複製二進制日誌文件
cp -a /application/mysql/logs/clsn-bin.* /data/backup/
截取日誌
zcat clsn_2017-12-22.sql.gz >clsn_2017-12-22.sql sed -n '22p' clsn_2017-12-22.sql mysqlbinlog -d clsn --start-position=339 clsn-bin.000008 -r bin.sql
須要恢復的日誌:
1.clsn_2017-12-22.sql 2.bin.sql grep -i drop bin.sql sed -i '/^drop.*/d' bin.sql
1.4.4 進行數據恢復
恢復數據
[root@db02 backup]# mysql <clsn_2017-12-22.sql [root@db02 backup]# mysql -e "show databases;" +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | clsn | | znix | | performance_schema | +--------------------+
查看數據庫
mysql> select * from test; +----+------+ | id | name | +----+------+ | 1 | clsn | | 2 | znix | | 3 | inca | | 4 | zuma | | 5 | kaka | +----+------+ 5 rows in set (0.00 sec)
恢復增量數據：
[root@db02 backup]# mysql clsn <bin.sql mysql> select * from test; +----+------+ | id | name | +----+------+ | 1 | clsn | | 2 | znix | | 3 | inca | | 4 | zuma | | 5 | kaka | | 6 | haha | | 7 | hehe | +----+------+ 7 rows in set (0.00 sec)
恢復完畢。
調整iptables容許用戶訪問.
1.4.5 多個binlog問題
mysqlbinlog -d clsn --start-position=339 clsn-bin.000009 clsn-bin.0000010 -r bin1.sql mysql clsn <bin1.sql
1.5 mysql數據庫實際生產慘案
1.5.1 發生背景
一、mysql服務器會在天天夜裏0點全量備份
二、某個開發人員某個陽光明媚的上午，喝着茶，優雅的誤刪除了clsn_oss（核心）數據庫。
三、致使公司業務異常中止，沒法正常提供服務。
1.5.2 怎麼解決的
一、當前系統進行評估。
什麼損壞了，有沒有備份，
恢復數據時間（誤操做的數據有關，備份、恢復策略），
恢復業務時間
二、恢復方案
（1）恢復0點的全備，到測試庫
（2）恢復0點開始到故障時間點的binlog，到測試庫
（3）將誤操做的數據導出，恢復到生產庫。
（4）檢驗數據是否是完整的（開發測試環境測試恢復成功數據庫）
（5）檢驗完成以後，從新開啓生產業務
1.5.3 項目總結
一、通過個人恢復處理，30分鐘總體業務從新提供服務（速度慢。。。）
二、在之後的工做中制定嚴格的開發規範，開發，開發。
三、未來制定更好的架構方案。
1.6 備份工具的選擇
數據量範圍：30G --> TB級別
1.6.1 數據量大，變換量小
（1）全備分花費的成本較高，mysqldump+binlog實現全備 + 增量備份，缺點是恢復成本比備份時間成本還高
（2）xtrabackup：能夠較長時間作一次全備，其他時間都是增量，全量備份空間成本很高若是數據量在30G-->TB級別的話，更推薦使用xtrabackup工具。
1.6.2 數據量小，變化量大
只須要考慮時間成本。
只用全備備份便可，兩種工具選擇均可以。恢復成本上xtrabackup小一些
1.6.3 數據量、變化量都大
時間成本和空間成本都要考慮了。
數據量達到PB或更高時（facebook），mysqldump可能成爲首選，佔用空間小，但技術成本高。須要對mysqldump進行二次開發（大數據量公司首選）。
1.7 xtrabackup備份軟件
percona公司官網 https://www.percona.com/
1.7.1 Xtrabackup介紹
Xtrabackup是由percona開源的免費數據庫熱備份軟件，它能對InnoDB數據庫和XtraDB存儲引擎的數據庫非阻塞地備份（對於MyISAM的備份一樣須要加表鎖）；mysqldump備份方式是採用的邏輯備份，其最大的缺陷是備份和恢復速度較慢，若是數據庫大於50G，mysqldump備份就不太適合。
Xtrabackup安裝完成後有4個可執行文件，其中2個比較重要的備份工具是innobackupex、xtrabackup
1）xtrabackup 是專門用來備份InnoDB表的，和mysql server沒有交互； 2）innobackupex 是一個封裝xtrabackup的Perl腳本，支持同時備份innodb和myisam，但在對myisam備份時須要加一個全局的讀鎖。 3）xbcrypt 加密解密備份工具 4）xbstream 流傳打包傳輸工具，相似tar 5）物理備份工具，在同級數據量基礎上，都要比邏輯備份性能好的多，特別是在數據量較大的時候，體現的更加明顯。
1.7.1 Xtrabackup優勢
1）備份速度快，物理備份可靠
2）備份過程不會打斷正在執行的事務（無需鎖表）
3）可以基於壓縮等功能節約磁盤空間和流量
4）自動備份校驗
5）還原速度快
6）能夠流傳將備份傳輸到另一臺機器上
7）在不增長服務器負載的狀況備份數據
8）物理備份工具，在同級數據量基礎上，都要比邏輯備份性能要好的多。幾十G到不超過TB級別的條件下。但在同數據量級別，物理備份恢復數據上有必定優點。
1.7.2 備份原理
拷貝數據文件、拷貝數據頁
對於innodb表能夠實現熱備。
(1)在數據庫還有修改操做的時刻，直接將數據文件備走，此時，備份走的數據對於當前mysql來說是不一致的。 (2)將備份過程當中的redo和undo一併備走。 (3)爲了恢復的時候，只要保證備份出來的數據頁lsn能和redo lsn匹配，未來恢復的就是一致的數據。redo應用和undo應用。
對於myisam表實現自動鎖表拷貝文件。
備份開始時首先會開啓一個後臺檢測進程，實時檢測mysql redo的變化，一旦發現有新的日誌寫入，馬上將日誌記入後臺日誌文件xtrabackup_log中，以後複製innodb的數據文件一系統表空間文件ibdatax，複製結束後，將執行flush tables with readlock,而後複製.frm MYI MYD等文件，最後執行unlock tables,最終中止xtrabackup_log
1.7.3 xtrabackup的安裝
安裝依賴關係
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL
下載軟件包，並安裝軟件
wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm yum -y install percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm
1.8 xtrabackup實踐操做
1.8.1 全量備份與恢復
這一階段會啓動xtrabackup內嵌的innodb實例，回放xtrabackup日誌xtrabackup_log，將提交的事務信息變動應用到innodb數據/表空間，同時回滾未提交的事務(這一過程相似innodb的實例恢復）。恢復過程以下圖：
備份
建立備份目錄
mkdir /backup -p
進行第一次全量備份
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123 --socket=/application/mysql/tmp/mysql.sock --no-timestamp /backup/xfull
恢復前準備
恢復數據前的準備(合併xtabackup_log_file和備份的物理文件)
innobackupex --apply-log --use-memory=32M /backup/xfull/
查看合併後的 checkpoints 其中的類型變爲 full-prepared 即爲可恢復。
[root@db02 full]# cat xtrabackup_checkpoints backup_type = full-prepared from_lsn = 0 to_lsn = 4114824 last_lsn = 4114824 compact = 0 recover_binlog_info = 0
破壞數據庫數據文件
[root@db02 full]# cd /application/mysql/data/ [root@db02 data]# ls auto.cnf db02.pid ibdata2 mysql mysql-bin.index world clsn haha ib_logfile0 mysql-bin.000001 oldboy db02.err ibdata1 ib_logfile1 mysql-bin.000002 performance_schema [root@db02 data]# \rm -rf ./* [root@db02 data]# ls [root@db02 data]# killall mysql
恢復方法
方法一:直接將備份文件複製回來
cp -a /backup/full/ /application/mysql/data chown -R mysql.mysql /application/mysql/data
方法二:使用innobackupex命令進行恢復(推薦)
[root@db02 mysql]# innobackupex --copy-back /backup/xfull [root@db02 mysql]# chown -R mysql.mysql /application/mysql/
說明：不管使用那種恢復方法都要恢復後需改屬組屬主，保持與程序一致。
[root@db02 data]# cd /application/mysql/data/ [root@db02 data]# ls clsn ibdata2 ibtmp1 performance_schema xtrabackup_info haha ib_logfile0 mysql world ibdata1 ib_logfile1 oldboy xtrabackup_binlog_pos_innodb
啓動是數據庫
[root@db02 data]# /etc/init.d/mysqld start
1.8.2 增量備份與恢復
innobackupex增量備份過程當中的"增量"處理，其實主要是相對innodb而言，對myisam和其餘存儲引擎而言，它仍然是全拷貝(全備份)
"增量"備份的過程主要是經過拷貝innodb中有變動的"頁"（這些變動的數據頁指的是"頁"的LSN大於xtrabackup_checkpoints中給定的LSN）。增量備份是基於全備的，第一次增備的數據必需要基於上一次的全備，以後的每次增備都是基於上一次的增備，最終達到一致性的增備。增量備份的過程以下，和全備的過程很相似，區別僅在第2步。
增量備份從哪增量？
基於上一次的備份進行增量。
redo默認狀況下是一組兩個文件，而且有固定大小。其使用的文件是一種輪詢使用方式，他不是永久的，文件隨時可能被覆蓋。
注意：千萬不要在業務繁忙時作備份。
備份什麼內容
一、可使用binlog做爲增量
二、自帶的增量備份，基於上次備份後的變化的數據頁，還要備份在備份過程當中的undo、redo變化
怎麼備份
1、先進行第一次全備
innobackupex --user=root --password=123 --no-timestamp /bakcup/xfull
對原庫作了修改，修改了小紅那行而後commit。
2、再進行增量備份
innobackupex --user=root --password=123 --incremental --no-timestamp --incremental-basedir=/backup/xfull/ /backup/xinc1
怎麼恢復
一、先應用全備日誌（--apply-log，暫時不須要作回滾操做--redo-only）
innobackupex --apply-log --redo-only /backup/xfull/
二、合併增量到全備中（一致性的合併）
innobackupex --apply-log --incremental-dir=/backup/xinc1 /backup/xfull/ innobackupex --apply-log /backup/xfull
三、合併完成進行恢復
方法一:直接將備份文件複製回來
cp -a /backup/full/ /application/mysql/data chown -R mysql.mysql /application/mysql/data
方法二:使用innobackupex命令進行恢復(推薦)
[root@db02 mysql]# innobackupex --copy-back /backup/xfull [root@db02 mysql]# chown -R mysql.mysql /application/mysql/
說明：不管使用那種恢復方法都要恢復後需改屬組屬主，保持與程序一致。
1.8.3 數據庫備份策略
每週的週日進行一次全備；週一到週六天天作上一天增量，每週輪詢一次。
xfull --apply-log --redo-only 保證last-lsn=週一增量開始lsn xinc1 合併週一的增量到全備，並apply-log --redo-only 保證last-lsn=週二增量開始lsn xinc2 合併週二的增量到全備，並apply-log --redo-only 保證last-lsn=週三增量開始lsn xinc3 合併週三的增量到全備，並apply-log --redo-only 保證last-lsn=週四增量開始lsn xinc4 合併週四的增量到全備，並apply-log --redo-only 保證last-lsn=週五增量開始lsn xinc5 合併週五的增量到全備，並apply-log --redo-only 保證last-lsn=週六增量開始lsn xinc6 合併週六的增量到全備，--apply-log 準備恢復便可
1.8.4 真實生產實戰案例分析
背景：某物流公司網站核心系統，數據量是220G，每日更新量100M-200M
備份方案： xtrabackup全備+增量
備份策略（crontab）：
一、週六 晚上0點全備
0 0 * * 6 zjs_full.sh ---這行能夠沒有
二、週一至周5、週日 是增量，基於上一天增量
0 1 * * 0-5 zjs_inc.sh---這行能夠沒有
故障場景：
週三的時候，下午兩點，開發人員誤刪除了一張表zjs_base，大約10G。
項目職責：
1) 指定恢復方案、利用現有備份;
2) 恢復誤刪除數據;
3) 制定運維、開發流程規範。
恢復流程：
a) 準備上週六全備。 b) 合併週日、週一 、週二增量。 c) 在測試庫恢復以上數據，數據的目前狀態應該週三凌晨1:00 d) 須要恢復的數據狀態是，下午2點鐘左右 e) 從1點開始的binlog恢復到刪除以前轉檯 f) 導出刪除的表zjs_base，恢復到生產庫，驗證數據可用性、完整性。 g) 啓動應用鏈接數據庫。
總結：通過30分鐘將誤刪表恢復了。服務總共中止40分鐘。
1.8.5 故障恢復小結
恢復思路：
一、首先確保斷開全部應用，保證數據的安全。
二、檢查用於恢復的備份存在嗎。
三、設計快速、安全恢復簡單方案，制定突發問題解決辦法。
具體恢復流程：
1、準備上週六全備，並--apply-log --redo-only 2、合併增量，週日、週一 、週二 --apply-log --redo-only 週三 --apply-log 3、在測試庫恢復以上數據，數據的目前狀態應該週三凌晨1:00 4、須要恢復的數據狀態是，下午2點鐘左右，刪除zjs_base以前的數據狀態 從1點開始的binlog恢復到刪除以前的那個events的position。 5、導出刪除的表zjs_base，恢復到生產庫，驗證數據可用性、完整性。 6、啓動應用鏈接數據庫。
肯定恢復所需時間
恢復窗口要多長？----> 預計3小時 和你恢復+驗證+意外狀況有關。 業務停多長時間？----> 6小時？或者更多？更少？
1.8.6 【模擬】生產事故恢復
數據建立階段
一、建立備份須要的目錄
mkdir full inc1 inc2
二、週日全備
innobackupex --user=root --password=123 --no-timestamp /backup/xbackup/full/
三、模擬數據變化
use oldboy create table test(id int,name char(20),age int); insert into test values(8,'outman',99); insert into test values(9,'outgirl',100); commit;
四、週一增量備份
innobackupex --user=root --password=123 --incremental --no-timestamp --incremental-basedir=/backup/xbackup/full/ /backup/xbackup/inc1
五、模擬數據變化
use oldboy insert into test values(8,'outman1',119); insert into test values(9,'outgirl1',120); commit;
六、週二的增量備份
innobackupex --user=root --password=123 --incremental --no-timestamp --incremental-basedir=/backup/xbackup/inc1 /backup/xbackup/inc2
7. 再插入新的行操做
use oldboy insert into test values(10,'outman2',19); insert into test values(11,'outgirl2',10); commit;
模擬誤操做事故
模擬場景，週二下午2點誤刪除test表
use oldboy; drop table test;
準備恢復數據
1.準備xtrabackup備份，合併備份
innobackupex --apply-log --redo-only /backup/xbackup/full innobackupex --apply-log --redo-only --incremental-dir=/backup/xbackup/inc1 /backup/xbackup/full innobackupex --apply-log --incremental-dir=/backup/xbackup/inc2 /backup/xbackup/full innobackupex --apply-log /backup/xbackup/full
2．確認binlog起點，準備截取binlog。
cd /backup/xbackup/inc2/ cat xtrabackup_binlog_info mysql-bin.000001 1121
3.截取到drop操做以前的binlog
mysqlbinlog --start-position=1121 /tmp/mysql-bin.000003 找到drop以前的event和postion號作日誌截取，假如 1437 mysqlbinlog --start-position=1121 --stop-position=1437 /tmp/mysql-bin.000003 >/tmp/incbinlog.sql
4．關閉數據庫、備份二進制日誌
/etc/init.d/mysqld stop cd /application/mysql/data/ cp mysql-bin.000001 /tmp
5.刪除MySQL全部數據
cd /application/mysql/data/ rm -rf *
恢復數據
1．將全量備份的數據恢復到數據目錄下
innobackupex --copy-back /backup/xbackup/full/ chown -R mysql.mysql /application/mysql/data/ /etc/init.d/mysqld start
2.恢復binlog記錄
set sql_log_bin=0 source /tmp/incbinlog.sql
1.8.7 xtarbackup導出
(1)「導出」表 導出表是在備份的prepare階段進行的，所以，一旦徹底備份完成，就能夠在prepare過程當中經過--export選項將某表導出了：
innobackupex --apply-log --export /path/to/backup
此命令會爲每一個innodb表的表空間建立一個以.exp結尾的文件，這些以.exp結尾的文件則能夠用於導入至其它服務器。
(2)「導入」表 要在mysql服務器上導入來自於其它服務器的某innodb表，須要先在當前服務器上建立一個跟原表表結構一致的表，然後才能實現將表導入：
mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;
而後將此表的表空間刪除：
mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
接下來，未來自於「導出」表的服務器的mytable表的mytable.ibd和mytable.exp文件複製到當前服務器的數據目錄，而後使用以下命令將其「導入」：(記得改權限)
mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
示例:
innobackupex --user=root --password=123 --no-timestamp /backup/xbackup/full/
進入到全備的數據庫目錄下
[root@db02 haha]# ls db.opt PENALTIES.frm PENALTIES.ibd PLAYERS.frm PLAYERS.ibd [root@db02 haha]# pwd /backup/xbackup/full/haha
導出表
[root@db02 haha]# innobackupex --apply-log --export /backup/xbackup/full/ [root@db02 haha]# ls db.opt PENALTIES.exp PENALTIES.ibd PLAYERS.exp PLAYERS.ibd PENALTIES.cfg PENALTIES.frm PLAYERS.cfg PLAYERS.frm
建立出同結構表
CREATE TABLE `PLAYERS` ( `PLAYERNO` int(11) NOT NULL, `NAME` char(15) NOT NULL, `INITIALS` char(3) NOT NULL, `BIRTH_DATE` date DEFAULT NULL, `SEX` char(1) NOT NULL, `JOINED` smallint(6) NOT NULL, `STREET` varchar(30) NOT NULL, `HOUSENO` char(4) DEFAULT NULL, `POSTCODE` char(6) DEFAULT NULL, `TOWN` varchar(30) NOT NULL, `PHONENO` char(13) DEFAULT NULL, `LEAGUENO` char(4) DEFAULT NULL, PRIMARY KEY (`PLAYERNO`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8
複製恢復數據到庫下
[root@db02 haha]# cp PLAYERS.ibd PLAYERS.exp /application/mysql/data/backup/ cp: overwrite `/application/mysql/data/backup/PLAYERS.ibd'? y
恢復數據
mysql> ALTER TABLE backup.PLAYERS DISCARD TABLESPACE; Query OK, 0 rows affected (0.00 sec)
1.8.8 innobackupex參數說明
| 參數 |
參數說明 |
| --compress |
該選項表示壓縮innodb數據文件的備份。 |
| --compress-threads |
該選項表示並行壓縮worker線程的數量。 |
| --compress-chunk-size |
該選項表示每一個壓縮線程worker buffer的大小，單位是字節，默認是64K。 |
| --encrypt |
該選項表示經過ENCRYPTION_ALGORITHM的算法加密innodb數據文件的備份，目前支持的算法有ASE128,AES192,AES256。 |
| --encrypt-threads |
該選項表示並行加密的worker線程數量。 |
| --encrypt-chunk-size |
該選項表示每一個加密線程worker buffer的大小，單位是字節，默認是64K。 |
| --encrypt-key |
該選項使用合適長度加密key，由於會記錄到命令行，因此不推薦使用。 |
| --encryption-key-file |
該選項表示文件必須是一個簡單二進制或者文本文件，加密key可經過如下命令行命令生成：openssl rand -base64 24。 |
| --include |
該選項表示使用正則表達式匹配表的名字[db.tb]，要求爲其指定匹配要備份的表的完整名稱，即databasename.tablename。 |
| --user |
該選項表示備份帳號。 |
| --password |
該選項表示備份的密碼。 |
| --port |
該選項表示備份數據庫的端口。 |
| --host |
該選項表示備份數據庫的地址。 |
| --databases |
該選項接受的參數爲數據名，若是要指定多個數據庫，彼此間須要以空格隔開；如："xtra_test dba_test"，同時，在指定某數據庫時，也能夠只指定其中的某張表。如："mydatabase.mytable"。該選項對innodb引擎表無效，仍是會備份全部innodb表。此外，此選項也能夠接受一個文件爲參數，文件中每一行爲一個要備份的對象。 |
| --tables-file |
該選項表示指定含有表列表的文件，格式爲database.table，該選項直接傳給--tables-file。 |
| --socket |
該選項表示mysql.sock所在位置，以便備份進程登陸mysql。 |
| --no-timestamp |
該選項能夠表示不要建立一個時間戳目錄來存儲備份，指定到本身想要的備份文件夾。 |
| --ibbackup |
該選項指定了使用哪一個xtrabackup二進制程序。IBBACKUP-BINARY是運行percona xtrabackup的命令。這個選項適用於xtrbackup二進制不在你是搜索和工做目錄，若是指定了該選項,innoabackupex自動決定用的二進制程序。 |
| --slave-info |
該選項表示對slave進行備份的時候使用，打印出master的名字和binlog pos，一樣將這些信息以change master的命令寫入xtrabackup_slave_info文件。能夠經過基於這份備份啓動一個從庫。 |
| --safe-slave-backup |
該選項表示爲保證一致性複製狀態，這個選項中止SQL線程而且等到show status中的slave_open_temp_tables爲0的時候開始備份，若是沒有打開臨時表，bakcup會馬上開始，不然SQL線程啓動或者關閉知道沒有打開的臨時表。若是slave_open_temp_tables在--safe-slave-backup-timeount （默認300秒）秒以後不爲0，從庫sql線程會在備份完成的時候重啓。 |
| --kill-long-queries-timeout |
該選項表示從開始執行FLUSH TABLES WITH READ LOCK到kill掉阻塞它的這些查詢之間等待的秒數。默認值爲0，不會kill任何查詢，使用這個選項xtrabackup須要有Process和super權限。 |
| --kill-long-query-type |
該選項表示kill的類型，默認是all，可選select。 |
| --ftwrl-wait-threshold |
該選項表示檢測到長查詢，單位是秒，表示長查詢的閾值。 |
| --ftwrl-wait-query-type |
該選項表示得到全局鎖以前容許那種查詢完成，默認是ALL，可選update。 |
| --galera-info |
該選項表示生成了包含建立備份時候本地節點狀態的文件xtrabackup_galera_info文件，該選項只適用於備份PXC。 |
| --stream |
該選項表示流式備份的格式，backup完成以後以指定格式到STDOUT，目前只支持tar和xbstream。 |
| --defaults-file |
該選項指定了從哪一個文件讀取MySQL配置，必須放在命令行第一個選項的位置。 |
| --defaults-extra-file |
該選項指定了在標準defaults-file以前從哪一個額外的文件讀取MySQL配置，必須在命令行的第一個選項的位置。通常用於存備份用戶的用戶名和密碼的配置文件。 |
| ----defaults-group |
該選項表示從配置文件讀取的組，innobakcupex多個實例部署時使用。 |
| --no-lock |
該選項表示關閉FTWRL的表鎖，只有在全部表都是Innodb表而且不關心backup的binlog pos點，若是有任何DDL語句正在執行或者非InnoDB正在更新時（包括mysql庫下的表），都不該該使用這個選項，後果是致使備份數據不一致，若是考慮備份由於得到鎖失敗，能夠考慮--safe-slave-backup馬上中止複製線程。 |
| --tmpdir |
該選項表示指定--stream的時候，指定臨時文件存在哪裏，在streaming和拷貝到遠程server以前，事務日誌首先存在臨時文件裏。在使用參數stream=tar備份的時候，你的xtrabackup_logfile可能會臨時放在/tmp目錄下，若是你備份的時候併發寫入較大的話 xtrabackup_logfile可能會很大(5G+)，極可能會撐滿你的/tmp目錄，能夠經過參數--tmpdir指定目錄來解決這個問題。 |
| --history |
該選項表示percona server 的備份歷史記錄在percona_schema.xtrabackup_history表。 |
| --incremental |
該選項表示建立一個增量備份，須要指定--incremental-basedir。 |
| --incremental-basedir |
該選項表示接受了一個字符串參數指定含有full backup的目錄爲增量備份的base目錄，與--incremental同時使用。 |
| --incremental-dir |
該選項表示增量備份的目錄。 |
| --incremental-force-scan |
該選項表示建立一份增量備份時，強制掃描全部增量備份中的數據頁。 |
| --incremental-lsn |
該選項表示指定增量備份的LSN，與--incremental選項一塊兒使用。 |
| --incremental-history-name |
該選項表示存儲在PERCONA_SCHEMA.xtrabackup_history基於增量備份的歷史記錄的名字。Percona Xtrabackup搜索歷史表查找最近（innodb_to_lsn）成功備份而且將to_lsn值做爲增量備份啓動出事lsn.與innobackupex--incremental-history-uuid互斥。若是沒有檢測到有效的lsn，xtrabackup會返回error。 |
| --incremental-history-uuid |
該選項表示存儲在percona_schema.xtrabackup_history基於增量備份的特定歷史記錄的UUID。 |
| --close-files |
該選項表示關閉再也不訪問的文件句柄，當xtrabackup打開表空間一般並不關閉文件句柄目的是正確的處理DDL操做。若是表空間數量巨大，這是一種能夠關閉再也不訪問的文件句柄的方法。使用該選項有風險，會有產生不一致備份的可能。 |
| --compact |
該選項表示建立一份沒有輔助索引的緊湊的備份。 |
| --throttle |
該選項表示每秒IO操做的次數，只做用於bakcup階段有效。apply-log和--copy-back不生效不要一塊兒用。 |
1.9 參考文獻
https://www.cnblogs.com/cchust/p/5452557.html http://www.cnblogs.com/gomysql/p/3650645.html xtrabackup 詳解 https://www.percona.com/software/mysql-database/percona-xtrabackup https://learn.percona.com/hubfs/Manuals/Percona_Xtra_Backup/Percona_XtraBackup_2.4/Percona-XtraBackup-2.4.9.pdf
- 1. Mysql 備份恢復與xtrabackup備份
- 2. xtrabackup備份（MySQL備份）與恢復
- 3. mysql備份恢復與xtrabackup備份
- 4. Xtrabackup備份恢復
- 5. xtrabackup 備份與恢復
- 6. Xtrabackup的備份與恢復
- 7. Xtrabackup備份與恢復
- 8. Xtrabackup流備份與恢復
- 9. MySQL備份恢復之XtraBackup
- 10. MySQL之Xtrabackup備份與恢復
- 更多相關文章...
- • MySQL數據庫備份（INTO OUTFILE） - MySQL教程
- • Redis的兩種備份（持久化）方式：RDB和AOF - Redis教程
- • 漫談MySQL的鎖機制
- • Composer 安裝與使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。