mysql備份與恢復-xtracebackup
阿新 • • 發佈：2018-12-30
因為percona打算放棄使用innobackupex備份工具，因此我們這裡也說明一下innobackupex的兄弟工具xtraceback工具的使用
這個工具的安裝可以參考上面的一些博文，上面詳細說明了innobackupex的備份與使用：https://www.cnblogs.com/wxzhe/p/10033983.html
首先我們來看一下xtracbackup的幫助文件：
[[email protected] ~]# 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 filesin 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是一款物理的線上備份工具，那麼其備份的原理是什麼？我們應該知道在備份過程資料時可以寫入的。
xtracebackup的備份過程詳解：http://www.cnblogs.com/zhoujinyi/p/5888271.html
下面通過例項來說明使用xtracebackup的備份與恢復
[[email protected] 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表。
下面通過一次完全備份，來理解xtracebackup備份的過程。
在備份過程中，您應該看到很多輸出顯示正在複製的資料檔案，以及日誌檔案執行緒反覆掃描日誌檔案並從中複製。
[[email protected] ~]# 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
檢視一下備份出來的檔案：
[[email protected] backup]# ls #這裡的資訊和innobackupex備份出來的資訊差不多，因為沒有開啟二進位制日誌，因此，少了二進位制日誌的相關資訊。 backup-my.cnf employees ib_buffer_pool ibdata1 mysql performance_schema sbtest sys xtrabackup_checkpoints xtrabackup_info xtrabackup_logfile [[email protected] backup]# cat xtrabackup_checkpoints backup_type = full-backuped #指明瞭這是一個完全備份 from_lsn = 0 to_lsn = 293834966 last_lsn = 293834975 compact = 0 recover_binlog_info = 0 [[email protected] 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備份時線上備份，也就是再備份的過程中，資料庫是可以進行操作的，備份的資料時間點自然就是不一致的，時間範圍是從備份開始到備份結束這段時間，因此在使用備份出來的資料進行恢復之前，首先要做的就是準備資料，利用重做日誌把資料恢復到同一個時間點。
您可以在任何機器上執行準備操作; 它不需要位於原始伺服器或您要還原的伺服器上。您可以將備份複製到實用程式伺服器並在那裡進行準備。
準備過程如下：
[[email protected] ~]# 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備份的資料恢復需要停掉原來的資料庫。
[[email protected] ~]# service mysqld stop #停掉資料庫 [[email protected] ~]# rm -fr /data/mysql/* #清空資料庫目錄 [[email protected] ~]# 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! [[email protected] ~]# chown -R mysql:mysql /data/mysql/ #修改資料庫目錄的屬主和屬組 [[email protected] ~]# service mysqld start #啟動資料庫 Starting MySQL. SUCCESS! [[email protected] ~]#
上面就是一個完整的資料庫備份與恢復過程，當然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進行比較。但是，您仍需要完整備份來恢復增量更改; 如果沒有完整備份作為基礎，增量備份將毫無用處。
第一步：完全備份：
[[email protected] ~]# xtrabackup --user=root --password=123456 --backup --target-dir=/root/backup/ -S /data/mysql/mysql.sock [[email protected] ~]# cd backup/ #這個檔案記錄了最後的lsn資訊 [[email protected] backup]# cat xtrabackup_checkpoints backup_type = full-backuped from_lsn = 0 to_lsn = 293839337 last_lsn = 293839346 compact = 0 recover_binlog_info = 0 [[email protected] backup]#
然後我們對資料庫做一些更改！
[[email protected] 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>
#如上，僅建立了一張表，插入了一行記錄！
開始做增量備份
[[email protected] ~]# xtrabackup --user=root --password=123456 -S /data/mysql/mysql.sock --backup --incremental-basedir=/root/backup/ --target-dir=/root/inc1
#--backup：指定操作是備份
＃--incremental-basedir：此次增量備份時基於哪一個備份檔案的。
#--target-dir： 指定增量備份的檔案地址
#檢視增量備份的檔案
[[email protected] ~]# cd backup/inc1/
[[email protected] 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
[[email protected] inc1]# cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 293839337
to_lsn = 293846059
last_lsn = 293846068
compact = 0
recover_binlog_info = 0
[[email protected] inc1]#
思考？這裡的增量備份時基於全備開始，如果我們還想繼續下一次的增量備份，該基於全備呢？還是基於第一個增量備份呢？回想一下增量備份時根據lsn來備份的，如果想要下一個增量備份，肯定是基於前面的一個增量備份開始的！
增量備份恢復操作
和上面的一樣，也需要先準備階段！
增量備份的步驟與完全備份的步驟不同。在完全備份中，執行兩種型別的操作以使資料庫保持一致：從日誌檔案中對資料檔案重放已提交的事務，並回滾未提交的事務。在準備增量備份時，必須跳過未提交事務的回滾，因為備份時未提交的事務可能正在進行中，並且很可能它們將在下一次增量備份中提交。您應該使用--apply-log-only該 選項來阻止回滾階段
準備的時候先prepare全備資料，如果有多個增量備份，則按照to_lsn的順序來執行prepare操作！
執行全備的prepare階段 [[email protected] ~]# xtrabackup --prepare --apply-log-only --target-dir=/root/backup/ #執行增量備份的prepare階段 [[email protected] ~]# 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目錄 [[email protected] ~]# xtrabackup --copy-back --target-dir=/root/backup/ [[email protected] ~]# chown -R mysql:mysql /data/mysql [[email protected] ~]# service mysqld start Starting MySQL.. SUCCESS! [[email protected] ~]# 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備份中已經說明了，不再贅述！