Mysql Backup and Recover

1 備份簡介

1.1 備份分類

數據庫備份，分爲冷備、熱備，全備與增量備份，邏輯備份與物理備份。以上三種不一樣的說法，是因爲側重點不一樣:css

類型	側重點
冷備與熱備	數據庫是否仍提供服務。不提供服務爲冷備,提供服務的同時進行備份爲熱備
全備與增量備份	備份全部數據爲全量，只備份自上次全量備份以來的有變更的數據爲增量
邏輯備份與物理備份	取數據方式：邏輯從數據庫取出數據而後以某種格式存儲
	物理備份直接拷貝數據文件

1.2 備份工具

如今主流的備份工具是mysqldump 和extrabackup(mariabackup). 其中 mysqldump 是邏輯備份工具，將數據從數據庫中讀取出，而後輸出到文本文件。咱們可使用平常的文本編輯工具直接查看和編輯。html

而xtrabackup 是percona 公司開發的Mysql物理備份開源工具。可是隨着MySQL被Oracle收購後，原MySQL之父，從新開發了一款MySQL: MariaDB, 成爲MySQL系列數據中的一個重要分支。不只支持MySQL的全部功能，還擁有MySQL 所不支持的存儲引擎，以及擁有更強大的性能。xtrabackup 目前不支持10.1.23以後的版本，由於Mariadb的新特性。因此Mariadb在xtrabackup的基礎上進行了二次開發，並集成到安裝包裏。該工具支持MySQL數據庫的全備和增量備份。java

2 邏輯備份與恢復

mysqldump 在不一樣的分支及版本中, 參數可能不盡相同，可是大部分功能及做用是相同的。下面是Mariadb 10.2.5 中的Mysqldump的基本用法、參數說明及示例。python

2.1 備份

mysqldump 的基本使用方法:mysql

Usage: mysqldump [OPTIONS] database [tables]
OR     mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR     mysqldump [OPTIONS] --all-databases [OPTIONS]

2.1.1 參數說明

這裏只列出平常使用的參數,linux

參數縮略	參數全稱	說明
-A	–all-databases	導出全部的數據庫,包括系統自帶的數據
-Y	–all-tablespaces	導出全部的表空間
-y	–no-tablespaces	不導出表空間信息
	–add-drop-database	在create database語句以前先輸出drop database語句
	–add-drop-table	在建表語句以前，有刪除表的SQL(DROP TABLE IF EXISTS)
		默認打開
	–add-drop-trigger	建立觸發器以前，若是有同名觸發器，先刪除
	–add-locks	插入數據前，先鎖表，默認打開,使用–skip-add-locks關閉
	–allow-keywords	導出時，容許關鍵詞做爲表的字段名
	–apply-slave-statements	導出的內容, 在change master語句以前，先輸出stop slave
		而且將 start slave 放到導出文件的末尾
-B	–databases	導出指定數據庫，多個數據庫名之間使用空格分隔
	–default-character-set	指定默認字符集
	–delayed-insert	使用 INSERT DELAYED 語法插入數據
	–dump-slave[=#]	此參數只適用於從節點. 值爲1, 會輸出"change master"命令,
		值爲2,"change master"命令會被註釋掉。同時會自動啓用
		–lock-all-tables，除非使用了–single-transaction
-F	–flush-logs	將內存中的數據寫入磁盤，須要注意的是,若是導出多個數據庫
		須要配合–lock-all-tables或者 –master-data參數使用
		不然，每導出一個庫就會執行一次flush logs
	–gtid	使用gtid 替代 master_log信息,與–master-data 或者
		–dump-slave配合使用
	–ignore-table	不導出某張表
	–include-master-host-port	與–dump-slave配合使用, 導出時，將mast_host,
		master_port 信息補全,默認是沒有的
-x	–lock-all-tables	在導出數據過程當中對全部表執行read lock鎖。並自動關閉
		–sgingle-transaction和–lock-tables
-l	–lock-tables	對全部表執行read lock，默認開啓，可以使用
		–skip-lock-tables關閉
	–master-data	鏈接主庫備份時使用, 值爲1, 輸出change master 命令
		到文件，值爲2時，change master 命令被註釋。使用此
		選項，會自動開啓–lock-all-tables, 除非另外指定了
		–single-transaction,在5.3以前，即便如此，也會
		在剛開始時，有個短暫的全局的read lock.
	–max-allowed-packet	與服務器數據交換時單次包最大容量,通常用於性能優化
	–net-buffer-length	網絡buffer大小，通常用於性能優化
-n	–no-create-db	導出內容不包含create database語句
-t	–no-create-info	導出內容，不包含create table語句
-d	–no-data	不導出表裏的數據
	–no-data-med	不導出管理外部數據的存儲引擎信息，默認開啓，
		能夠經過–skip-no-data-med關閉
	–order-by-primary	導出的數據按照主鍵排序(若是有的話),可是導出時間明顯加長
-p	–password	MySQL用戶密碼
-P	–port	mysql 端口
-q	–quick	不查詢buffer,直接導出
	–replace	使用replace into語句代替insert into語句
-r	–result-file	將導出內容輸出到該文件
-R	–routines	導出函數和存儲過程
	–single-transaction	單事務處理，保證數據一致性,會自動關閉–lock-tables.
		僅支持InnoDB
	–dump-date	記錄導出時間，默認開啓，使用–skip-dump-date可關閉
	–skip-opt	關閉部分默認選項，好比 –add-drop-table, –add-locks,
		–create-options, –quick, –extended-insert,
		–lock-tables, –set-charset, and –disable-keys.
-S	–socket	指定用於鏈接MySQL的socket file
-T	–tab	只有在MySQL服務器上導出時生效，每張表一個文件
–tables		導出表，替代-B(–datebases)選項
–triggers		導出表時，導出與之相關的觸發器，默認開啓
		使用–skip-triggers關閉
-u	–user=name	鏈接MySQL的用戶
-v	–verbose	導出時，輸出每一個階段的明細
-V	–version	輸出Mysqldump的版本
-w	–where=name	根據where指定的條件，導出查詢結果

2.1.2 使用示例

備份全部庫c++

mysqldump -uroot -proot --all-databases -r alldb.sql

備份指定數據庫正則表達式

mysqldump -uroot -proot -B test -r structure.sql

備份表算法

mysqldump -uroot -proot --tables test.a1 test.a2 > tables.sql

備份表中部分數據sql

mysqldump -uroot -proot --tables test.a1 test.a2 --where="create_date>'2019-01-01'" -r partial_data.sql

備份函數與存儲過程

mysqldump -uroot -proot --routines --no-create-db --no-data --no-tablespaces --no-create-info -r routines.sql

備份結構可是不備份數據

mysqldump -uroot -proot -B test --no-data > structure_$(date "+%Y%m%d_%H%M%S").sql

2.2 恢復

邏輯備份的恢復很是簡單，由於備份的結果是可讀取的sql文件。能夠經過mysql 的 source 命令執行, 不過通常使用"<"來進行恢復。假如備份文件是test.sql,恢復示例以下:

mysql -uroot -proot < test.sql

3 物理備份與恢復

mysql 物理庫的物理備份，特別要感謝percona公司開發的xtrabackup 工具，使Mysql 具有了不停機物理備份(熱備)的能力。

而Mariadb在xtrabackup的基礎上進行了二次開發。使其可以在10.1.23及以後的版本中進行在線熱備。

3.1 percona-xtrabackup

xtrabackup 只支持innodb和XtraDB 存儲引擎。雖然如今innodb 是最流行的。可是爲了追求速度，不少數據庫會使用MYSIAM存儲引擎。爲了支持MYSIAM，咱們可使用innobackupex.

Percona 在2.3 版本用C重寫了 innobackupex ，innobackupex 功能所有集成到 xtrabackup 裏面，只有一個 binary，另外爲了使用上的兼容考慮，innobackupex 做爲 xtrabackup 的一個軟連接。版本2.3 擺脫了以前2個進程協做的負擔，架構上明顯要好於以前版本，該版本以後推薦使用 xtrabackup 腳本進行備份。

3.1.1 版本兼容性

mysql5.1在源碼中配備了兩個版本的innodb存儲引擎源碼：innobase和innodb_plugin，編譯安裝的時候能夠經過參數 –with-plugins=innobase,innodb_plugin來指定將innodb存儲引擎引入，具體這兩個參數引入對編譯後的mysql產生怎樣的差別，後面再作解析。然而對於Percona XtraBackup，在release版本中有2.0，2.1，2.2三個大版本，而後每個版本都是與mysql發佈的innodb存儲引擎版本對應，舉例來講：

percona-xtrabackup-2.0.8在BUILD.txt中指定了utils/build.sh參數以下：

Build an xtrabackup binary against the specified InnoDB flavor.

Usage: build.sh CODEBASE
where CODEBASE can be one of the following values or aliases:
  innodb50         | 5.0                   build against innodb 5.1 builtin, but should be compatible with MySQL 5.0
  innodb51_builtin | 5.1                   build against built-in InnoDB in MySQL 5.1
  innodb51         | plugin                build against InnoDB plugin in MySQL 5.1
  innodb55         | 5.5                   build against InnoDB in MySQL 5.5
  innodb56         | 5.6,xtradb56,         build against InnoDB in MySQL 5.6
                   | mariadb100
  xtradb51         | xtradb,mariadb51      build against Percona Server with XtraDB 5.1
                   | mariadb52,mariadb53
  xtradb55         | galera55,mariadb55    build against Percona Server with XtraDB 5.5

而在percona-xtrabackup-2.1.9在BUILD.txt中指定了utils/build.sh參數以下：

The script needs the codebase for which the building is targeted, you must
provide it with one of the following values or aliases:

  ================== =========  =============================================
  Value              Alias      Server
  ================== =========  =============================================
  innodb51           plugin build against InnoDB plugin in MySQL 5.1
  innodb55           5.5    build against InnoDB in MySQL 5.5
  xtradb51           xtradb     build against Percona Server with XtraDB 5.1
  xtradb55           xtradb55   build against Percona Server with XtraDB 5.5
  innodb56           5.6        build against InnoDB in MySQL 5.6
  ================== =========  =============================================

從以上兩個版本對比中，咱們知道，從2.1版本開始，percona-xtrabackup 取消對Mysql innodb51_builtin 的支持。

所以在安裝percona xtrabackup 的時候，要先確認即將安裝的xtrabackup版本是否支持當前的MySQL版本。

3.1.2 安裝

下載 perconna-xtrabackup
下載Mysql 源碼包。由於perconna-xtrabackup 版本與mysql 版本是有對應關係的。若是不知道須要安裝哪一個版本，能夠先進行安裝，在沒有mysql 源碼包的狀況下，會有提示

安裝示例以下：

wget https://www.percona.com/downloads/XtraBackup/XtraBackup-2.1.9/source/percona-xtrabackup-2.0.8.tar.gz
tar -xf percona-xtrabackup-2.0.8.tar.gz
cd percona-xtrabackup-2.0.8
wget https://cdn.mysql.com/archives/mysql-5.1/mysql-5.1.59.tar.gz
./utils/build.sh 5.1
cp ./innobackupex /usr/bin/
cp ./usr/xtrabackup_51 /usr/bin/xtrabackup

3.1.3 參數詳解

--apply-log
  經過應用錄下的事務日誌文件xtrabackup_logfile，在BACKUP-DIR目錄準備一個備份。頁創建一個新的事務日誌文件。innoDB的配置是從innobackupex備份時創建的文件backup-my.cnf讀取。
--close-files
  不保持文件被打開。默認備份時tablespace不關閉，但若是表空間很大而且不適合任何限制，有一個可選的方法是關閉再也不訪問的文件。使用該選項會產生不一致的備份。
--compact
  創建一個忽略耳機索引頁的簡潔備份。
--compress
創建一個innoDB數據文件的壓縮備份。它直接提交給xtrabackup的子進程
--compres-threads=#
並行壓縮的工做進場數量，它直接提交給xtrabackup的子進程
--compress-chunk-size=#
指定每一個壓縮進程的內部工做緩衝區的尺寸，用字節來測量。它直接提交給xtrabackup的子進程
--copy-back
複製全部的備份到他們原來的位置
--databases=LIST
指定將要備份的數據庫列表。支持databasename.tablename格式，若是沒指定參數，則備份全部數據庫
--decompress
解壓全部以選項--compress備份的，結尾是.qp的文件。使用參數--parallel容許多個文件同時被解密和或解壓。
--decrypt=ENCRPYTION-ALGORITHM
解密用--encrpyt選項加密的以.xbcrypt結尾的文件。
--defaults-file=[my.cnf]
經過制定一個字符串來設置MySQL的默認選項
--defaults-extra-file=[my.cnf]
在從標準的默認文件中取值默認以前的額外文件。接收一個字符串做爲選項
--defaults-group=GROUP-NAME
若是用了Mysqld_multi，可設置讀取配置文件的特定組
--encrypt=ENCRYPTION-ALGORITHM
該選項指引xtrabackup使用參數ENCRYPTION_ALGORITHM參數制定的算法，加密innoDB數據文件的備份，它直接指向子進程
--encrypt-key=ENCRYPTION_KEY
指示xtrabackup在備份時使用ENCRYPTION_KEY指定的key作--encrypt加密。它直接傳給子進程
--encrypt-key-file=ENCRYPTION_KEY_FILE
當用選項--encrpyt加密時使用存儲在ENCRYPTION_KEY_FILE裏存儲的加密key
--encrypt-threads=#
指定並行加密的工做線程數。它直接傳給子進程
--encrypt-chunk-size=#
指定每一個加密進程使用的內粗工做緩衝區的尺寸，以字節計算大小
--export
它用於導出單個表用於導入另外一個server
--extra-lsndir=DIRECTORY
指定xtrabackup_checkpoints文件的保留目錄
--force-non-empty-directories
  該參數使得選項--copy-back or --move-back選項傳輸文件到非空目錄。不存在的文件將被覆蓋。若是選項--copy-back or --move-back必須從備份目錄到一個已經存在的目標目錄，則將失敗
--galera-info
  該選項在備份時創建包含本地節點狀態xtrabackup_galera_info文件。用於執行Percona-XtraDB-Cluster備份
--host=HOST
  執行經過TCP/IP鏈接訪問數據庫的主機，它傳給mysql的子進程
--ibbackup=IBBACKUP-BINARY
  接收字符串參數，它用來指定要使用的xtrabackup binary、
--include=REGEXP
  指定一個正則表達式，用語匹配格式爲databasename.tablename的表名稱，它傳遞給--tables選項
--incremental
  創建一個增量備份，傳遞給xtrabackup的子進程。該參數能夠和參數--incremental-lsn or --incremental-basedir配合使用。
--incremental-basedir=DIRECTORY
  指定一個包換全庫備份的目錄做爲增量備份的基礎數據庫
--incremental-dir=DIRECTORY
  指定增量備份與全庫備份合併去創建一個新的全備份的目錄。
--incremental-lsn=LSN
  指定增量備份將要開始的LSN，它替代選項--incremental-basedir
--kill-long-queries-timeout=SECONDS
  該選項指定innobackupex在開始FLUSH TABLES WITH READ LOCK和殺掉這些阻礙他的查詢之間的時間的等待時間，以秒計算，默認爲0，意味着innobackupex不嘗試殺任何查詢，
  該選項須要process and super權限
--kill-long-query-type=all|select
  指定解鎖全局鎖時將被殺掉的查詢類型，默認是all
--lock-wait-timeout=SECONDS
  運行FLUSH TABLES WITH READ LOCK以前，innobackupex等待阻塞查詢的時間數(秒數)
--lock-wait-threashold=SECONDS
  選項指定查詢運行時間閥值，當innobackupex發現長運行查詢伴隨着--lock-wait-timeout的一個非0值，
--lock-wait-query-type=all|update
  指定innobackupex發出一個全局鎖以前什麼類型的查詢容許完成
--lock-copy-interval=#
  指定日誌日誌複製線程檢車完成的時間間隔，以毫秒計算
--move-back
  移動以前的全部備份從一個備份目錄到他們的原始位置
--no-lock
  不容許使用flush tables with read lock表鎖。若是你的全部表示INNODB而且你不關心二進制日誌備份的位置。若是有任何DDL語句被執行或任何非INNODB表上的update操做，這個選項就不能使用
--notimestamp
  把備份放在一個經過選項backup-root-dir指定的子目錄裏
--no-version-check
  禁止版本檢查
--parallel=NUMBER-OF-THREADS
  該選項接收一個整數，xtarbackup子進程將用於同時備份文件的併發數。若是有多個.ibd文件能夠並行，若是隻有一個表空間文件，則該選項無效
--password=PASSWORD
  指定鏈接到數據庫的帳戶密碼
--port=PORT
  該選項指定經過TCP/IP鏈接到數據庫時所用的端口
--rebuild-indexes
  只有用--apply-log選項時它纔有效，當應用日誌後使得xtrabackup重建全部的二級索引。通常用於準備簡約備份
--rebuild-threas=NUMBER-OF-THREADS
  當一塊兒使用選項--apply-log and --rebuild-indexes選項時纔有用，使用後，當重建索引時，xtrabackup處理表空間時用必定數量的線程的並行模式
--redo-only
  選項用於準備全庫備份和合並處最有一個備份外的全部增量備份。它強制xtrabackup忽略「rollback」階段只作「redo」.
--rsync
  使用rsync工具優化本地文件傳輸。它讓xtrabackup使用rsync複製全部非innoDB文件，而不是使用多個cp
--safe-slave-backup
  中止從SQL進程並等待啓動備份直到slave_open_temp_tables的值爲0。若是沒有打開臨時表，備份會進行，不然SQL進程將啓動並直到沒有打開的臨時表時中止。若是slave_open_temp_tables在--
safe-slave-backup-timeout秒後沒有變成0，則備份會失敗。備份結束後，從SQL進程將從新啓動
--safe-slave-backup-timeout=SECONDS
  --safe-slave-backup要等slave_open_temp_tables變成0的時間，默認爲300秒
--scopt=SCP-OPTIONS
  當參數--remost-host指定時傳遞給scp的參數
--slave-info
  當備份一個複製從庫操做的時候用，它打印二進制日誌的position和主庫的名字，它頁把這些信息寫入xtrabackup_slave_info文件做爲一個CHANGE MASTER命令
--socket=SOCKET
  指定鏈接到本地數據庫sever時使用的一個unix domain socket，它沒有修改的傳入mysql子進程
--sshopt=SSH-OPTIONS
  當使用參數--remost-host時，使用ssh的命令行參數
--stream=STREMNAME
  當使用流備份時使用的特定格式。備份將以特定格式傳到STDOUT。支持的格式爲tar and xbstream
--tables-file=FILE
  指定備份的表的列表，格式爲database.tablename
--throttle=IOS
  指定I/O操做的數量/秒。該參數只適用於備份階段。不適用於參數--apply-log,--copy-back
--tmpdir=DIRECTORY
  在參數--stream使用時指定，是指臨時文件被存儲的位置
--use-memory=#
  該參數只能和參數--apply-log配合使用，被用於xtrabackup作creash恢復時準備鎖使用的內存量(單位：字節)。也支持其餘單位，如：1MB,1M,1GB,1G
--user=USER
  指定鏈接到mysql時使用的用戶名
--version
  顯示innobackupex的版本信息和版權等信息
--version-check
  指定該選項後，innobackupex將在創建一個鏈接後，在備份階段執行一個版本檢查

3.1.4 備份與恢復

備份與恢復的示例與mariabackup的使用方法幾乎是同樣的。參見增量備份與恢復.

3.2 mariabackup

因爲 xtrabackup不支持MariaDB的InnoDB頁壓縮和靜態數據加密技術,因此Mariadb 基於 Percona XtraBackup 2.3.8 開發了開源產品 mariabackup ,並在MariaDB 10.1.23 和 MariaDB 10.2.7, GA版本 MariaDB 10.1.26 and MariaDB 10.2.10 中首次發佈。用於對InnoDB，Aria和MyISAM表進行物理在線備份.

mariabackup是集成在MariaDB安裝包中的，所以不須要額外安裝

3.2.1 參數詳解

mariabackup的參數與extrabackup的參數用法與意義上基本相同，其使用方法與意義在下面表格中進行詳細說明。其中參數選項部分，在使用時，應在其前面加上「–」, 如："mariabackup –backup"。

以下：

參數選項	意義
apply-log-only	在10.1中，增量備份時可使用此參數，與prepare使用,只應用
	apply stage的binlog,忽略crash recovery stage的binlog
	10.2及之後的版本中再也不使用。
backup	執行備份操做,將生成的備份文件存放於target-dir指定的路徑中
binlog-info	告訴mariabackup如何讀取binlog的信息。有三個可用值：
	OFF: 不讀binlog
	ON: 讀取binlog,並在能夠保證數據一致性的位置執行blocking
	AUTO: 讀取binlog,並在支持的狀況下使用ON或者lockless選項
	LOCKLESS: mariabackup不支持此值。
close-files	是否關閉文件句柄。打開時，mariabackup能夠處理DDL。關閉時
	mariabackup對大文件的備份更加可控,可是有可能致使數據不一致
	,所以我的建議不關閉。保持默認打開狀態。
compress	10.2.25中還是可用的。可是在10.3官方文檔中明確說明爲
	deprecated.對應的解壓參數也過時了。建議使用stream
	使用第三方的壓縮庫對數據流進行壓縮，示例以下:
	備份時進行加密和壓縮：
	mariabackup –user=root –backup –stream=xbstream \|
	gzip \| openssl enc -aes-256-cbc -k mypass >
	backup.xb.gz.enc
	解密和解壓縮：
	openssl enc -d -aes-256-cbc -k mypass -in
	backup.xb.gz.enc \| gzip -d\| mbstream -x
copy-back	將備份恢復至datadir變量指向的路徑。要求該路徑爲空。配合
	參數force-non-empty-directories可恢復至非空路徑
core-file	當導出時遇到fatal signals,能夠加上此參數，導出內核信息
	便於分析定位和解決問題。
databases	指定須要備份的數據或者表。對的，這個參數支持備份表，其語法:
	–databases="db[.table][db[.table] …]"
	若是要導出大部分庫或者表，可使用databases-exclude選項
	將不須要的庫或者表過濾掉，用法與databases是同樣的。
databases-file	將須要導出的庫或者表放到一個文件中，經過此參數來指定該文件
datadir	指定數據文件路徑。mariabackup將從這個路徑讀取數據進行備份

print-defaults	輸出各類參數及變量的值，並退出備份程序
no-defaults	不讀MySQL的參數文件。也就是不讀my.cnf文件
defaults-file	指定mariabackup默認讀取的參數文件。指的是My.cnf文件,能夠不
	用默認的my.cnf. 此參數應在其餘全部參數以前。
defaults-extra-file	defaults-file讀完後，讀取此參數配置的參數文件,經過此參數
	文件能夠修改 defaults-file中的默認配置
defaults-group	指定讀取參數文件中的哪一部份內容。好比讀取[mariabackup]
	中的配置。
export	與prepare配合使用,會生成一個cfg文件。針對file-per-table
	每一個表文件(表空間)會生成一個cfg文件，該文件可用於恢復備份
	中的部份內容，好比某張表或者某個分區。
extra-lsndir	複製一份xtrabackup_checkpoints、xtrabackup_info到另
	外一個路徑
force-non-empty-directories	與copy-back或者move-back配合使用。當datadir路徑非空時
	使用此參數，將強制恢復到datadir路徑。
ftwrl-wait-query-type	與backup配合使用,讓mariabackup等待相對應的操做完成再
	執行global lock. 有三個可用值: all\| update \| select
ftwrl-wait-threshold	與ftwrl-wait-query-type配合使用，SQL執行時間大於此參數
	設置的值時，進入等待，直到ftwrl-wait-timeout的時間。
	前提是ftwrl-wait-timeout 大於0.
ftwrl-wait-timeout	默認0，表示不等待任何SQL執行完即執行global lock.
	單位秒。表示mariabackup最多等待時間，超事後再也不等待。
incremental-basedir	對該路徑進行增量備份(備份上次備份以後有修改過的文件)
	與backup參數配合使用。
incremental-dir	針對已經prepare的路徑。對prepare路徑進行增量處理。
	主要是應用.delta文件和binlog文件。
incremental-force-scan	與incremental-basedir配合使用，對將要備份的文件進行全
	掃描，即便有對應的位圖信息(經過位圖信息保存增量對比)
incremental-history-name	爲每次增量指定一個邏輯名。
incremental-lsn	備份時只備份比lsn大的文件。
innobackupex	經過此參數，能夠啓用innobackupex的特性。
innodb-adaptive-hash-index	備份時開啓innodb adaptive hash index,也是默認設置
	關閉此特性，使用–skip-innodb-adaptive-hash-index
innodb-autoextend-increment	備份文件自動擴展,每次擴展的大小，單位M。

verbose	輸出備份日誌明細
version	輸出備份工具的版本號
target-dir	備份文件的存儲路徑
prepare	將備份文件進行數據一致性處理，以進行恢復。在徹底備份的狀況下
	文件不是時間點一致的，由於它們是在不一樣時間進行的快照,須要通
	mariabackup –prepare 處理成一致狀態。增量恢復時，須要使用
	prepare命令和incremental-dir選項將增量備份應用到全備中去.

3.2.2 使用mariabackup搭建主從複製

默認場景

從庫的 MariaDB 已安裝,並配置好參數文件。
主庫已運行一段時間,不方便停業務

準備工做
- 主庫建立複製用戶
  
  主庫建立用於複製數據的用戶;
```
GRANT replication slave ON *.* TO 'rep1'@'10.1.61.10' IDENTIFIED BY 'repl123';
```
  note
  
  10.1.61.10 爲從庫IP。
- 建立存儲備份的路徑
  
  在主備兩端都須要建立。
```
#建立備份路徑, mysql 用戶須要有權限訪問
mkdir -p /home/mysql/backup
```
- 安裝依賴包
  
  備庫須要安裝qpress工具(前提是備份時使用 compress 參數,若是不使用該參數也能夠 ,只要空間足夠). 請到qpress官網下載最新版本。當前是 qpress-11 . 對於 Linux系統只須要如下三步:
```
wget http://www.quicklz.com/qpress-11-linux-x64.tar
tar xvf qpress-11-linux-x64.tar
cp qpress /usr/bin
```

備份主庫

備份

mariabackup -uroot --backup --target-dir=/home/mysql/backup --all-databases --use-memory=10G

備份示例:

[root@tycxdb2 backup]#  mariabackup -uroot --backup --target-dir=/home/mysql/backup --all-databases --use-memory=10G
[00] 2019-08-08 23:11:42 Connecting to MySQL server host: localhost, user: root, password: not set, port: not set, socket: not set
[00] 2019-08-08 23:11:42 Using server version 10.2.25-MariaDB-log
mariabackup based on MariaDB server 10.2.25-MariaDB Linux (x86_64)
[00] 2019-08-08 23:11:42 uses posix_fadvise().
[00] 2019-08-08 23:11:42 cd to /home/mysql/data/
[00] 2019-08-08 23:11:42 open files limit requested 0, set to 1024
[00] 2019-08-08 23:11:42 mariabackup: using the following InnoDB configuration:
[00] 2019-08-08 23:11:42 innodb_data_home_dir =
[00] 2019-08-08 23:11:42 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2019-08-08 23:11:42 innodb_log_group_home_dir = ./
[00] 2019-08-08 23:11:42 InnoDB: Using Linux native AIO
[00] 2019-08-08 23:11:42 using O_DIRECT
........ 內容過多省略 .....
mariabackup: Stopping log copying thread.[00] 2019-08-08 23:45:00 >> log scanned up to (793437226795)

[00] 2019-08-08 23:45:00 >> log scanned up to (793437226795)
[00] 2019-08-08 23:45:00 Executing UNLOCK TABLES
[00] 2019-08-08 23:45:00 All tables unlocked
[00] 2019-08-08 23:45:00 Copying ib_buffer_pool to /home/mysql/backup/ib_buffer_pool
[00] 2019-08-08 23:45:00         ...done
[00] 2019-08-08 23:45:00 Backup created in directory '/home/mysql/backup/'
[00] 2019-08-08 23:45:00 MySQL binlog position: filename 'mysql-bin.000939', position '48267434', GTID of the last change '0-22-190568113'
[00] 2019-08-08 23:45:00 Writing backup-my.cnf
[00] 2019-08-08 23:45:00         ...done
[00] 2019-08-08 23:45:00 Writing xtrabackup_info
[00] 2019-08-08 23:45:00         ...done
[00] 2019-08-08 23:45:00 Redo log (from LSN 793366546585 to 793437226795) was copied.
[00] 2019-08-08 23:45:00 completed OK!

note

物理備份的速度至關快,mysql datadir 路徑218G 數據 34分鐘備份完成,備份文件201G，若是空間充足，建議不使用 compress 選項，雖然雖然節省了空間和傳輸時間，可是解壓耗時至關長, 另外不可使用 prepare 選項對備份文件應用日誌, 恢復到另一個數據庫的時候會存在問題。
use-memory 能夠加快導出的速度，可是要注意本機的可用物理內容。

將備份傳送至目標服務器

scp /home/mysql/backup 192.168.111.20:/home/mysql/backup

備份恢復

數據文件一致性處理 在徹底備份的狀況下，文件不是時間點一致的，由於進行快照的時間點不同。若是嘗試在未prepare數據的狀況下還原數據庫，雖然操做上支持恢復，可是在啓動的時候仍會進行數據recovery。

運行帶 /prepare/選項的 /mariabackup/命令會使數據文件進行統一，達到數據一致性的目的，從而將其還原到MariaDB Server後不會有異常。

使用增量備份時，須要 prepare 選項和 incremental-dir 選項配合使用以使用增量備份中的文件進行恢復。

mariabackup --prepare --target-dri=/home/mysql/backup --user root

示例:

  mariabackup --user root --prepare --target-dir=./
mariabackup based on MariaDB server 10.2.25-MariaDB Linux (x86_64)
[00] 2019-08-09 01:07:25 cd to /home/mysql/backup/
[00] 2019-08-09 01:07:25 This target seems to be not prepared yet.
[00] 2019-08-09 01:07:25 mariabackup: using the following InnoDB configuration for recovery:
[00] 2019-08-09 01:07:25 innodb_data_home_dir = .
[00] 2019-08-09 01:07:25 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2019-08-09 01:07:25 innodb_log_group_home_dir = .
[00] 2019-08-09 01:07:25 InnoDB: Using Linux native AIO
[00] 2019-08-09 01:07:25 Starting InnoDB instance for recovery.
[00] 2019-08-09 01:07:25 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Uses event mutexes
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Using Linux native AIO
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Number of pools: 1
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Using SSE2 crc32 instructions
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Completed initialization of buffer pool
2019-08-09  1:07:25 139813501150976 [Note] InnoDB: page_cleaner coordinator priority: -20
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Highest supported file format is Barracuda.
2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Starting crash recovery from checkpoint LSN=793366562214
2019-08-09  1:07:27 139813761947776 [Note] InnoDB: Starting a batch to recover 7054 pages from redo log.
2019-08-09  1:07:40 139813559899904 [Note] InnoDB: To recover: 2396 pages from log
2019-08-09  1:07:55 139813761947776 [Note] InnoDB: Read redo log up to LSN=793393743872
2019-08-09  1:07:55 139813761947776 [Note] InnoDB: Starting a batch to recover 6218 pages from redo log.
2019-08-09  1:08:10 139813543114496 [Note] InnoDB: To recover: 1785 pages from log
2019-08-09  1:08:21 139813761947776 [Note] InnoDB: Starting final batch to recover 3572 pages from redo log.
2019-08-09  1:08:25 139813559899904 [Note] InnoDB: To recover: 1325 pages from log
2019-08-09  1:08:29 139813761947776 [Note] InnoDB: Last binlog file './mysql-bin.000939', position 48267434
[00] 2019-08-09 01:08:30 Last binlog file ./mysql-bin.000939, position 48267434

恢復數據
```
mariabackup --defaults-file=/etc/my.cnf --rsync --copy-back --target-dir=/home/mysql/backup/
```
這裏的copy-back 的目標路徑是 –defualts-file 中匹配的datadir。就是從target-dir中將備份恢復到 datadir中。
啓動從庫
```
systemctl start mysqld
```

創建主從複製關係

查看主的binlog起始點因爲以前準備工做中已經建立了複製用戶, 這一步只須要修改從庫的master信息。而 master 信息咱們經過備份文件中的 xtrabackup_binlog_info 文件來查看。文件內容示例:
```
# cat xtrabackup_binlog_info
mysql-bin.000938        658662639       0-22-190059068
```
第一列對應master_log_file，第二列對應master_log_pos, 第三列主gtid值。

啓動從庫MySQL

systemctl start mysqld

copy-back 後，首次啓動,可能會花費比較長的時間，由於要進行數據一致性處理。也可能僅一次啓動沒法完成數據recover,須要屢次從新啓動。啓動時,注意觀察日誌,示例以下:

     ...........
2019-08-08 22:37:41 140011134244608 [Note] InnoDB: To recover: 3497 pages from log
2019-08-08 22:39:26 140012383484032 [Note] InnoDB: 5 transaction(s) which must be rolled back or cleaned up in total 22784714 row operations to undo
2019-08-08 22:39:26 140012383484032 [Note] InnoDB: Trx id counter is 383051520
2019-08-08 22:39:26 140012383484032 [Note] InnoDB: Starting final batch to recover 2661 pages from redo log.
2019-08-08 22:39:26 140011159422720 [Note] InnoDB: To recover: 2660 pages from log
2019-08-08 22:39:29 140012383484032 [Note] InnoDB: Last binlog file './mysql-bin.000938', position 658662639
2019-08-08 22:39:30 140012383484032 [Note] InnoDB: 128 out of 128 rollback segments are active.
2019-08-08 22:39:30 140011067102976 [Note] InnoDB: Starting in background the rollback of recovered transactions
2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-08-08 22:39:30 140012383484032 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Waiting for purge to start
2019-08-08 22:39:30 140012383484032 [Note] InnoDB: 5.7.26 started; log sequence number 793713315141
2019-08-08 22:39:30 140010019874560 [Note] InnoDB: Loading buffer pool(s) from /home/mysql/data/ib_buffer_pool
2019-08-08 22:39:30 140012383484032 [Note] Plugin 'FEEDBACK' is disabled.
2019-08-08 22:39:30 140012383484032 [Note] Semi-sync replication initialized for transactions.
2019-08-08 22:39:30 140012383484032 [Note] Semi-sync replication enabled on the master.
2019-08-08 22:39:30 140012383484032 [Note] Recovering after a crash using tc.log
2019-08-08 22:39:30 140012383484032 [Note] Starting crash recovery...
2019-08-08 22:39:30 140012383484032 [Note] Crash recovery finished.
2019-08-08 22:39:30 140012383484032 [Note] Server socket created on IP: '::'.
2019-08-08 22:39:30 140012383484032 [Note] Reading of all Master_info entries succeeded
2019-08-08 22:39:30 140012383484032 [Note] Added new Master_info '' to hash table
2019-08-08 22:39:30 140012383484032 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '10.2.25-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution
2019-08-08 22:39:30 140010019874560 [Note] InnoDB: Buffer pool(s) load completed at 190808 22:39:30

配置主從關係

change master to master_host='10.1.61.9',master_port=3306,master_user='rep1',master_password='repl123',master_log_file='mysql-bin.000938',master_log_pos=658662639;

開始主從複製

啓動主從複製，並確認複製進程是否正常。
```
mysql -e "start slave; show slave status\G"
```

3.2.3 增量備份與恢復

進行增量備份與恢復，首先要進行全量備份，再進行增量備份，而後將增量備份應用至全量備份。不支持壓縮過的備份。

全量備份

mariabackup --backup --target-dir=/backup/fullbackup  -uroot -Proot

增量備份

mariabackup --backup --target-dir=/backup/incremental_backup \
 --incremental-basedir=/backup/fullbackup -uroot -Proot

prepare全量備份

mariabackup -uroot -Proot --prepare --target-dir=/backup/fullbackup --apply-log-only

合併全量備份與增量備份

mariabackup -uroot -Proot --prepare --target-dir=/backup/fullbackup/ \
  --incremental-dir=/backup/incremental_backup/   --apply-log-only

將合併好的文件複製到數據文件路徑 恢復以前，先確認一下目標路徑是否爲空。儘可能爲空，若確實要恢復至不爲空的路徑中，須要額外使用參數 –force-non-empty-directories .

恢復的目標路徑，默認是/etc/my.cnf 中的datadir配置。若是須要恢復到其餘位置可使用 –datadir 選項從新指定數據文件路徑。
```
mariabackup -uroot -Proot --copy-back --target-dir=/backup/fullbackup/
```
恢復完成後，注意查看datadir及其中文件的屬組

Mysql 備份與恢復