紅薯餅or南瓜餅?
疫情下在家裡閒的無事，做了一盤紅薯餅吃，吃的正香，想著前二天談到數據的備份的重要性，不如索性把之前做過的備份整理一下：
基於Xtrabackup做備份恢復
優勢：
1、快速可靠的進行完全備份
2、在備份的過程中不會影響到事務
3、支持數據流、網絡傳輸、壓縮，所以它可以有效的節約磁盤資源和網絡帶寬。
4、可以自動備份校驗數據的可用性。
安裝Xtrabackup
[root@BD ~]# rpm -ivh percona-xtrabackup-2.1.4-656.rhel6.i686.rpm
其最新版的軟件可從 http://www.percona.com/software/percona-xtrabackup/ 獲得
注意：在備份數據庫的時候，我們應該具有權限，但需要注意的是應該給備份數據庫時的用戶最小的權限，以保證安全性，
1前提：
應該確定採用的是單表一個表空間，否則不支持單表的備份與恢復。
在配置文件裡邊的mysqld段加上
innodb_file_per_table = 1
2備份策略
完全備份+增量備份+二進制日誌
3準備個目錄用於存放備份數據
[root@BD ~]# makdir /innobackup
4做完全備份：
[root@BD ~]# innobackupex --user=root --password=mypass /innobackup/
注：
1)、只要在最後一行顯示 innobackupex: completed OK!，就說明你的備份是正確的。
2)、另外要注意的是每次備份之後，會自動在數據目錄下創建一個以當前時間點命名的目錄用於存放備份的數據，那我們去看看都有什麼
[root@BD 2019-09-12_11-03-04]# ls
backup-my.cnf ibdata1 performance_schema xtrabackup_binary xtrabackup_checkpoints
hellodb mysql test xtrabackup_binlog_info xtrabackup_logfile
[root@BD 2019-09-12_11-03-04]#
xtrabackup_checkpoints ：備份類型、備份狀態和LSN(日誌序列號)範圍信息；
xtrabackup_binlog_info ：mysql服務器當前正在使用的二進制日誌文件及至備份這一刻為止二進制日誌事件的位置。
xtrabackup_logfile ：非文本文件，xtrabackup自己的日誌文件
xtrabackup_binlog_pos_innodb ：二進制日誌文件及用於InnoDB或XtraDB表的二進制日誌文件的當前position。
backup-my.cnf ：備份時數據文件中關於mysqld的配置
5回到mysql服務器端對數據進行更新操作
mysql> use hellodb;
mysql> delete from students where StuID>=24;
6增量備份
innobackupex --user=root --password=mypass --incremental /innobackup/--incremental-basedir=/innobackup/2019-09-12_11-03-04/
--incremental 指定備份類型
--incremental-basedir= 指定這次增量備份是基於哪一次備份的，這裡是完全備份文件,這樣可以把增量備份的數據合併到完全備份中去
7第二次增量
先去修改數據
mysql> insert into students (Name,Age,Gender,ClassID,TeacherID) values ('tom',33,'M',2,4);
innobackupex --user=root --password=mypass --incremental /innobackup/ --incremental-basedir=/innobackup/2019-09-12_11-37-01/
這裡只須要把最後的目錄改為第一次增量備份的數據目錄即可
8最後一次對數據更改但是沒做增量備份
mysql> delete from coc where id=14;
9把二進制日誌文件備份出來，(因為最後一次修改，沒做增量備份，要依賴二進制日誌做時間點恢復)
[root@BD data]# cp mysql-bin.000003 /tmp/
10模擬數據庫崩潰
[root@BD data]# service mysqld stop
[root@BD data]# rm -rf *
恢復前準備
11對完全備份做數據同步
[root@BD ~]# innobackupex --apply-log --redo-only /innobackup/2019-09-12_11-03-04/
12對第一次增量做數據同步
innobackupex --apply-log --redo-only /innobackup/2019-09-12_11-03-04/ --incremental-basedir=/innobackup/2019-09-12_11-37-01/
13對第二次增量做數據同步
innobackupex --apply-log --redo-only /innobackup/2019-09-12_11-03-04/ --incremental-basedir=/innobackup/2019-09-12_11-45-53/
--apply-log 的意義在於把備份時沒commit的事務撤銷，已經commit的但還在事務日誌中的應用到數據庫
注：
對於xtrabackup來講，它是基於事務日誌和數據文件備份的，備份的數據中可能會包含尚未提交的事務或已經提交但尚未同步至數據庫文件中的事務，還應該對其做預處理，把已提交的事務同步到數據文件，未提交的事務要回滾。因此其備份的數據庫，不能立即拿來恢復。
預處理的過程：
首先對完全備份文件只把已提交的事務同步至數據文件，要注意的是有增量的時候，不能對事務做數據回滾，不然你的增量備份就沒有效果了。
然後把第一次的增量備份合併到完全備份文件內，
以此類推，把後幾次的增量都合併到前一次合併之後的文件中，這樣的話，我們只要拿著完全備份+二進制日誌，就可以做時間點恢復。
14數據恢復
[root@BD ~]# service mysqld stop
[root@BD data]# rm -rf * 模擬數據庫崩潰
[root@BD ~]# innobackupex --copy-back /innobackup/2019-09-12_11-03-04/
--copy-back數據庫恢復，後面跟上備份目錄的位置
15檢測：
[root@BD ~]# cd /mydata/data/
[root@BD data]# chown mysql:mysql *
[root@BD data]#service mysqld start
檢測結果數據正常。
閱讀更多 問我35 的文章
