mysql備份與恢復-xtracebackup

由於percona打算放棄使用innobackupex備份工具，所以咱們這裏也說明一下innobackupex的兄弟工具xtraceback工具的使用html

這個工具的安裝能夠參考上面的一些博文，上面詳細說明了innobackupex的備份與使用：https://www.cnblogs.com/wxzhe/p/10033983.htmlnode

首先咱們來看一下xtracbackup的幫助文檔：mysql

[root@test3 ~]# xtrabackup --help xtrabackup: recognized server arguments: xtrabackup: recognized client arguments: --user=root --password=* --user=root --password=* --host=localhost xtrabackup version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c) Open source backup tool for InnoDB and XtraDB ...... Usage: [xtrabackup [--defaults-file=#] --backup | xtrabackup [--defaults-file=#] --prepare] [OPTIONS] Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf The following groups are read: xtrabackup mysqld The following options may be given as the first argument: ....... 後面是一些參數信息

xtracebackup是一款物理的在線備份工具，那麼其備份的原理是什麼？咱們應該知道在備份過程數據時能夠寫入的。ios

xtracebackup的備份過程詳解：http://www.cnblogs.com/zhoujinyi/p/5888271.html算法

下面經過實例來講明使用xtracebackup的備份與恢復

[root@test3 backup]# xtrabackup --user=root --password=123456 --backup --target-dir=backup/ xtrabackup: recognized server arguments: xtrabackup: recognized client arguments: --user=root --password=* --user=root --password=* --host=localhost --user=root --password=* --backup=1 --target-dir=backup/ 
181230 11:39:15  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;host=localhost' as 'root' (using password: YES). Failed to connect to MySQL server: DBI connect(';mysql_read_default_group=xtrabackup;host=localhost','root',...) failed: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) at - line 1314
181230 11:39:15 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set Failed to connect to MySQL server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2).

#這個報錯是由於MySQL5.7是源碼安裝，sock文件不在默認的/var/lib/mysql下面，能夠作個軟鏈接指定到/var/lib/mysql/mysql.sock這裏，
#或者使用「-S」參數，指定mysql.sock的文件位置

xtracebackup2.3版本以前不能備份innodb的表，而innobackupex能夠備份innodb的表，所以在2.3以前的版本一般使用innobackupex，innobackupex對xtracebackup作了封裝，在備份innodb的表時使用innobackupex，而在備份非innodb表時內部調用接口使用了xtracebackup工具。由於這兩個工具中一個是使用perl寫的，另外一個是使用c寫的，通訊相對困難。在xtracebackup2.4以後，重寫了這兩個，都使用c寫的，把innobackupex的功能附加到了xtracebackup中，也就是xtracebackup既能夠備份非innodb表也能夠備份innodb表。sql

下面經過一次徹底備份，來理解xtracebackup備份的過程。數據庫

在備份過程當中，您應該看到不少輸出顯示正在複製的數據文件，以及日誌文件線程反覆掃描日誌文件並從中複製。服務器

[root@test3 ~]# xtrabackup --user=root --password=123456  --backup --target-dir=backup/   #target-dir參數指定備份文件存在的目錄 xtrabackup: recognized server arguments: xtrabackup: recognized client arguments: --user=root --password=* --backup=1 --target-dir=backup/ 
181230 11:48:02  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'root' (using password: YES). 181230 11:48:02 version_check Connected to MySQL server 181230 11:48:02 version_check Executing a version check against the server... 181230 11:48:02 version_check Done. 181230 11:48:02 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set #鏈接mysql server Using server version 5.7.22 xtrabackup version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c) xtrabackup: uses posix_fadvise(). xtrabackup: cd to /data/mysql/                                                                    #首先備份innodb表 xtrabackup: open files limit requested 0, set to 1024 xtrabackup: using the following InnoDB configuration: xtrabackup: innodb_data_home_dir = . xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 50331648 InnoDB: Number of pools: 1
181230 11:48:03 >> log scanned up to (293834975) xtrabackup: Generating a list of tablespaces InnoDB: Allocated tablespace ID 17 for mysql/slave_worker_info, old maximum was 0
181230 11:48:03 [01] Copying ./ibdata1 to /root/backup/ibdata1 181230 11:48:03 [01]        ...done
181230 11:48:03 [01] Copying ./mysql/slave_worker_info.ibd to /root/backup/mysql/slave_worker_info.ibd 181230 11:48:03 [01]        ...done
181230 11:48:03 [01] Copying ./mysql/server_cost.ibd to /root/backup/mysql/server_cost.ibd ......... 181230 11:48:08 Executing FLUSH NO_WRITE_TO_BINLOG TABLES... 181230 11:48:08 Executing FLUSH TABLES WITH READ LOCK... #加上讀鎖，開始備份non-innodb表 181230 11:48:08 Starting to backup non-InnoDB tables and files 181230 11:48:08 [01] Copying ./performance_schema/socket_summary_by_instance.frm to /root/backup/performance_schema/socket_summary_by_instance.frm 181230 11:48:08 [01]        ...done
181230 11:48:08 [01] Copying ./performance_schema/socket_summary_by_event_name.frm to /root/backup/performance_schema/socket_summary_by_event_name.frm 181230 11:48:08 [01]        ...done
181230 11:48:08 [01] Copying ./performance_schema/users.frm to /root/backup/performance_schema/users.frm 181230 11:48:08 [01]        ...done
181230 11:48:08 [01] Copying ./performance_schema/hosts.frm to /root/backup/performance_schema/hosts.frm ............ 181230 11:48:11 Finished backing up non-InnoDB tables and files 181230 11:48:11 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS... #把日誌刷新到磁盤 xtrabackup: The latest check point (for incremental): '293834966' xtrabackup: Stopping log copying thread. .181230 11:48:11 >> log scanned up to (293834975) 181230 11:48:11 Executing UNLOCK TABLES  #完成non-innodb表的備份  181230 11:48:11 All tables unlocked #全部的表解鎖 181230 11:48:11 [00] Copying ib_buffer_pool to /root/backup/ib_buffer_pool 181230 11:48:11 [00]        ...done
181230 11:48:11 Backup created in directory '/root/backup/'
181230 11:48:11 [00] Writing /root/backup/backup-my.cnf 181230 11:48:11 [00]        ...done
181230 11:48:11 [00] Writing /root/backup/xtrabackup_info 181230 11:48:11 [00]        ...done xtrabackup: Transaction log of lsn (293834966) to (293834975) was copied. 181230 11:48:11 completed OK!
181230 11:48:08 [01]        ...done

查看一下備份出來的文件：app

[root@test3 backup]# ls #這裏的信息和innobackupex備份出來的信息差很少，由於沒有開啓二進制日誌，所以，少了二進制日誌的相關信息。 backup-my.cnf employees ib_buffer_pool ibdata1 mysql performance_schema sbtest sys xtrabackup_checkpoints xtrabackup_info xtrabackup_logfile [root@test3 backup]# cat xtrabackup_checkpoints backup_type = full-backuped  #指明瞭這是一個徹底備份 from_lsn = 0 to_lsn = 293834966 last_lsn = 293834975 compact = 0 recover_binlog_info = 0 [root@test3 backup]# cat xtrabackup_info uuid = ba508f21-0be5-11e9-8fc2-fa336351fc00 name = tool_name = xtrabackup tool_command = --user=root --password=... --backup --target-dir=backup/ tool_version = 2.4.12 ibbackup_version = 2.4.12 server_version = 5.7.22 start_time = 2018-12-30 11:48:02 end_time = 2018-12-30 11:48:11 lock_time = 0 binlog_pos = innodb_from_lsn = 0 innodb_to_lsn = 293834966 partial = N incremental = N format = file compact = N compressed = N encrypted = N

xtracebackup備份時在線備份，也就是再備份的過程當中，數據庫是能夠進行操做的，備份的數據時間點天然就是不一致的，時間範圍是從備份開始到備份結束這段時間，所以在使用備份出來的數據進行恢復以前，首先要作的就是準備數據，利用重作日誌把數據恢復到同一個時間點。socket

您能夠在任何機器上運行準備操做; 它不須要位於原始服務器或您要還原的服務器上。您能夠將備份複製到實用程序服務器並在那裏進行準備。

準備過程以下：

[root@test3 ~]# xtrabackup --prepare --target-dir=backup/
......
......
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 293839318
181230 14:22:32 completed OK!

恢復過程

恢復過程和以前使用innobackupex工具有份恢復的過程是同樣的，須要注意的是，xtracebackup和innobackupex備份的數據恢復須要停掉原來的數據庫。

[root@test3 ~]# service mysqld stop #停掉數據庫 [root@test3 ~]# rm -fr /data/mysql/*             #清空數據庫目錄 [root@test3 ~]# xtrabackup --copy-back --target-dir=/root/backup/       #恢復數據，其實就是一個copy過程 。。。。。。 181230 14:28:17 [01]        ...done
181230 14:28:17 [01] Copying ./xtrabackup_info to /data/mysql/xtrabackup_info 181230 14:28:17 [01]        ...done
181230 14:28:17 completed OK! [root@test3 ~]# chown -R mysql:mysql /data/mysql/       #修改數據庫目錄的屬主和屬組 [root@test3 ~]# service mysqld start #啓動數據庫 Starting MySQL. SUCCESS! [root@test3 ~]#

上面就是一個完整的數據庫備份與恢復過程，固然xtracebackup仍是有不少參數的，能夠在使用的時候查看！

說兩個參數吧！ --galera-info        This options creates the xtrabackup_galera_info file
                      which contains the local node state at the time of the backup. Option should be used when performing the backup of Percona-XtraDB-Cluster. Has no effect when backup locks are used to create the backup.
 #咱們公司使用的mariadb集羣，所以備份的時候會加上這個選項，備份一些集羣信息。 --slave-info This option is useful when backing up a replication slave server. It prints the binary log position and name of the master server. It also writes this information to the "xtrabackup_slave_info" file as a "CHANGE MASTER" command. A new slave for this master can be set up by starting a slave server on this backup and issuing a "CHANGE MASTER" command with the binary log position saved in the "xtrabackup_slave_info" file.
                      #這個就不用說了，是一些slave的信息。

上面是一個完整實例說明全備的備份與恢復，下面來講明一個增量備份的用法！

增量備份

摘自官方文檔：增量備份

增量備份有效，由於每一個InnoDB頁面都包含一個日誌序列號或LSN。該LSN是整個數據庫系統的版本號。每一個頁面的LSN顯示它最近的更改。

增量備份會複製其LSN比先前的增量備份或完整備份的LSN更新的每一個頁面。有兩種算法用於查找要複製的此類頁面集。第一個可用於全部服務器類型和版本的是經過讀取全部數據頁來直接檢查頁面LSN。Percona Server提供的第二個功能是在服務器上啓用更改的頁面跟蹤功能，該功能將在更改頁面時記錄這些功能。而後，該信息將在緊湊的單獨的所謂位圖文件中寫出。該xtrabackupbinary將使用該文件只讀取增量備份所需的數據頁，從而可能節省許多讀取請求。若是xtrabackup二進制文件找到位圖文件，則默認啓用後一種算法。即便位圖數據可用，也能夠指定xtrabackup --incremental-force-scan 讀取全部頁面。

增量備份實際上並不將數據文件與先前備份的數據文件進行比較。實際上，若是您知道其LSN，則可使用它來執行增量備份，甚至不須要先前的備份。增量備份只是讀取頁面並將其LSN與最後一個備份的LSN進行比較。可是，您仍須要完整備份來恢復增量更改; 若是沒有完整備份做爲基礎，增量備份將毫無用處。

第一步：徹底備份：

[root@test3 ~]# xtrabackup --user=root --password=123456 --backup --target-dir=/root/backup/ -S /data/mysql/mysql.sock [root@test3 ~]# cd backup/                    #這個文件記錄了最後的lsn信息 [root@test3 backup]# cat xtrabackup_checkpoints backup_type = full-backuped from_lsn = 0 to_lsn = 293839337 last_lsn = 293839346 compact = 0 recover_binlog_info = 0 [root@test3 backup]#

而後咱們對數據庫作一些更改！

[root@test3 backup]# mysql -uroot -p123456 -S /data/mysql/mysql.sock mysql: [Warning] Using a password on the command line interface can be insecure. Welcome to the MySQL monitor.  Commands end with ; or \g. Your MySQL connection id is 6 Server version: 5.7.22-log MySQL Community Server (GPL) Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> use sbtest; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> create table test(dt datetime); Query OK, 0 rows affected (0.03 sec) mysql> insert into test select now(); Query OK, 1 row affected (0.00 sec) Records: 1  Duplicates: 0  Warnings: 0 mysql> select * from test; +---------------------+
| dt                  |
+---------------------+
| 2018-12-30 14:50:07 |
+---------------------+
1 row in set (0.00 sec) mysql>

#如上，僅建立了一張表，插入了一行記錄！

開始作增量備份

[root@test3 ~]# xtrabackup --user=root --password=123456 -S /data/mysql/mysql.sock --backup --incremental-basedir=/root/backup/ --target-dir=/root/inc1

#--backup：指定操做是備份
＃--incremental-basedir：這次增量備份時基於哪個備份文件的。
#--target-dir：　　　　　　　指定增量備份的文件地址

#查看增量備份的文件
[root@test3 ~]# cd backup/inc1/
[root@test3 inc1]# ls
backup-my.cnf  ib_buffer_pool  ibdata1.meta  performance_schema  sys                     xtrabackup_checkpoints  xtrabackup_logfile
employees      ibdata1.delta   mysql         sbtest              xtrabackup_binlog_info  xtrabackup_info
[root@test3 inc1]# cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 293839337
to_lsn = 293846059
last_lsn = 293846068
compact = 0
recover_binlog_info = 0
[root@test3 inc1]#

思考？這裏的增量備份時基於全備開始，若是咱們還想繼續下一次的增量備份，該基於全備呢？仍是基於第一個增量備份呢？回想一下增量備份時根據lsn來備份的，若是想要下一個增量備份，確定是基於前面的一個增量備份開始的！

增量備份恢復操做

和上面的同樣，也須要先準備階段！

增量備份的步驟與徹底備份的步驟不一樣。在徹底備份中，執行兩種類型的操做以使數據庫保持一致：從日誌文件中對數據文件重放已提交的事務，並回滾未提交的事務。在準備增量備份時，必須跳過未提交事務的回滾，由於備份時未提交的事務可能正在進行中，而且極可能它們將在下一次增量備份中提交。您應該使用--apply-log-only該選項來阻止回滾階段

準備的時候先prepare全備數據，若是有多個增量備份，則按照to_lsn的順序來執行prepare操做！

執行全備的prepare階段 [root@test3 ~]# xtrabackup --prepare --apply-log-only --target-dir=/root/backup/
#執行增量備份的prepare階段 [root@test3 ~]# xtrabackup --prepare --target-dir=/root/backup/ --incremental-dir=/root/inc1/
#將增量文件和全備文件附件在一塊兒

特別須要注意一點：

xtrabackup --apply-log-only should be used when merging all incrementals except the last one. That’s why the previous line doesn’t contain the 
xtrabackup --apply-log-only option. Even if the xtrabackup --apply-log-only was used on the last step, backup would still be consistent but in
 that case server would perform the rollback phase.

#--apply-log-only參數應該被用於除最後一個增量備份以外的全部的增量備份（最後一個增量備份不使用），緣由有點不太理解，先這樣用。

數據準備完成以後，就會恢復了，和以前的過程是同樣的！

停掉MySQL服務，清空datadir目錄 [root@test3 ~]# xtrabackup --copy-back --target-dir=/root/backup/ [root@test3 ~]# chown -R mysql:mysql /data/mysql [root@test3 ~]# service mysqld start Starting MySQL.. SUCCESS! [root@test3 ~]# mysql -uroot -p123456 -S /data/mysql/mysql.sock #驗證增量備份 mysql: [Warning] Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: 5.7.22-log MySQL Community Server (GPL) Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> use sbtest; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> select * from test; +---------------------+
| dt                  |
+---------------------+
| 2018-12-30 14:50:07 |
+---------------------+

能夠看到增量備份已經恢復成功！

後續：

在實際中可能會更常常遇到基於時間點的恢復，譬如我常常遇到的是恢復到某天的23:59:59的數據，若是這樣的話，這個增量可能沒法知足，所以建議使用二進制日誌來作增量備份。

關於二進制日誌的增量備份，在上一篇博文中innobackupex備份中已經說明了，再也不贅述！