採用流式備份好處就不多說了 官方推薦 這裏就是說下備份完成之後要怎麼回覆
解壓備份文件
xtrabackup --decompress --remove-original --parallel=4 --target-dir=/home/backup/20190701160001/
注意這裏需要安裝官方解壓依賴的qpress ，或者pkgs.org可以自行下載並解壓安裝：
[root@localhost home]#tar xvf qpress-11-linux-x64.tar
[root@localhost home]#cp qpress /usr/bin
這裏說明下參數
--decompress 解壓參數 這就不多說了
--remove-original 這個參數的意義就是解壓完成後並刪除壓縮文件
--parallel 多線程解壓 加速
準備備份文件
解壓完的文件是不能直接用來恢復的 需要進行prepare
xtrabackup --prepare --apply-log --target-dir=/home/xbackdata/mysql
這裏說法有點多XtraBackup備份恢復模擬實踐，percona-xtrabackup使用如果是完整備份沒有增備就不需要加–apply-log-only 如果是有增備數據，必須在除最後一次增備的prepare之外都要加–apply-log-only（innobackupex 對應的是 --redo-only），這個參數的作用咱們看下官方的解釋：
The xtrabackup --prepare step for incremental backups is not the same as for full backups. In full backups,
two types of operations are performed to make the database consistent: committed transactions are replayed from the
log file against the data files, and uncommitted transactions are rolled back. You must skip the rollback of uncommitted
transactions when preparing an incremental backup, because transactions that were uncommitted at the time of your
backup may be in progress, and it’s likely that they will be committed in the next incremental backup. You should use
the xtrabackup --apply-log-only option to prevent the rollback phase.
Warning: If you do not use the xtrabackup --apply-log-only option to prevent the rollback phase,
then your incremental backups will be useless. After transactions have been rolled back, further incremental
backups cannot be applied.
--redo-only
This option should be used when preparing the base full backup and when merging all incrementals except
the last one. It is passed directly to xtrabackup’s xtrabackup --apply-log-only option. This forces
xtrabackup to skip the “rollback” phase and do a “redo” only. This is necessary if the backup will have
incremental changes applied to it later. See the xtrabackup documentation for details.
這個參數就是控制備份恢復過程中未提交的事務是否進行回滾 比如prepare第一個備份 將爲conmmit的事務回滾了 數據就丟失了，進行第二個備份prepare時 又對上一回滾的數據提交了 但是實際已經回滾 最終就導致數據丟失無法繼續恢復
備份原有mysql文件目錄
這裏最好是備份下 萬一恢復失敗了 還可以回滾，也可以忽略
將prepare之後的文件拷貝到mysql數據目
xtrabackup --copy-back --target-dir=/home/xbackdata/mysql
授權
這一步容易忽略 不是啥多大問題 但是通過日誌在分析出來浪費時間
chown -R mysql:mysql /home/mysqldata/mysql/
啓動mysql
service mysqld start
從binlog中繼續恢復數據到出問題的時間點（mysqlbinlog將binlog轉成sql）
參考：mysql通過mysqldump和mysqlbinlog恢復數據，binlog恢復數據失敗解決方案xtrabackup中記錄了binlog的文件起始位置，找打備份文件所在目錄：
root@localhost 20190701160001]# cat xtrabackup_binlog_info
mysql-bin.000007 191 416cf17c-97ba-11e9-803f-005056be27d7:1-6
我們看到start-position是191 GTID是 416cf17c-97ba-11e9-803f-005056be27d7:1-6
下一步就是找到binlog文件並進行解析：
mysqlbinlog --no-defaults -vv --skip-gtids --start-position=191 -d back mysql-bin.000007>4.sql # -d back是指定數據庫名稱解析
解析完成之後就可以打開找到出問題的sql所在的前一個sql的position 比如是345
然後進行指定position區間恢復
mysqlbinlog --no-defaults -vv --skip-gtids --start-position=191 --stop-position=345 -d back mysql-bin.000007>4.sql
這樣就得到了最終從備份之後到出問題之前的sql
導入從binlog恢復出來的sql文件
mysql -uroot -p <test_2016-08-02.sql