Xtrabackup備份與恢復

  • 一、Xtrabackup介紹

   Percona-xtrabackup是 Percona公司開發的一個用于MySQL數據庫物理熱備的備份工具,支持MySQL、Percona server和MariaDB,開源免費,是目前較為受歡迎的主流備份工具。xtrabackup只能備份innoDB和xtraDB兩種數據引擎的表,而不能備份MyISAM數據表。

MySQL冷備、mysqldump、MySQL熱拷貝都無法實現對數據庫進行增量備份。在實際生產環境中增量備份是非常實用的,如果數據大于50G或100G,存儲空間足夠的情況下,可以每天進行完整備份,如果每天產生的數據量較大,需要定制數據備份策略。例如每周實用完整備份,周一到周六實用增量備份。而Percona-Xtrabackup就是為了實現增量備份而出現的一款主流備份工具,

xtrabackup包含兩個主要的工具,即xtrabackup和innobackupex,二者區別如下:

(1)xtrabackup只能備份innodb和xtradb兩種引擎的表,而不能備份myisam引擎的表;

(2)innobackupex是一個封裝了xtrabackup的Perl腳本,支持同時備份innodb和myisam,但在對myisam備份時需要加一個全局的讀鎖。還有就是myisam不支持增量備份

  • 二、Xtrabackup優點

(1)備份速度快,物理備份可靠

(2)備份過程不會打斷正在執行的事務(無需鎖表)

(3)能夠基于壓縮等功能節約磁盤空間和流量

(4)自動備份校驗

(5)還原速度快

(6)可以流傳將備份傳輸到另外一臺機器上

(7)在不增加服務器負載的情況備份數據

  • 三、Xtrabackup備份原理

Xtrabackup備份流程圖(xtrabackup備份過程中,先備份innodb表,再備份非innodb表):

?

(1)innobackupex啟動后,會先fork一個進程,用于啟動xtrabackup,然后等待xtrabackup備份ibd數據文件;

(2)xtrabackup在備份innoDB數據是,有2種線程:redo拷貝線程和ibd數據拷貝線程。

xtrabackup進程開始執行后,會啟動一個redo拷貝的線程,用于從最新的checkpoint點開始順序拷貝redo.log;

這時xtrabackup記下LSN并將redo log拷貝到備份目標目錄下的xtrabackup_logfile文件中。由于拷貝需要一定時間,如果在拷貝時間段內有日志寫入,將導致拷貝的日志和MySQL的redo log不一致,所以xtrabackup還有一個后臺進程監控著mysql的redo log,每秒監控一次,當MySQL的redo log有變化,該監控進程會立即將變化的內容寫入到xtrabackup_logfile文件,這樣就能保證拷貝走的redo log中記錄了一切變化。但是這也是有風險的,因為redo是輪訓式循環寫入的,如果某一時刻有非常大量的日志寫到redo log中,使得還沒開始復制的日志就被新日志覆蓋了,這樣會日志丟失,并報錯。

再啟動ibd數據拷貝線程,進行拷貝innodb表的數據文件(即表空間文件.ibd文件和ibdata1)

注意,此時不拷貝innodb的frm文件。

這里是先啟動redo拷貝線程的。在此階段,innobackupex進行處于等待狀態(等待文件被創建)

(4)xtrabackup拷貝完成ibd數據文件后,會通知innobackupex(通過創建文件),同時xtrabackup進入等待狀態(redo線程依舊在拷貝redo.log)

(5)innobackupex收到xtrabackup通知后哦,執行FLUSH TABLES WITH READ LOCK(FTWRL),取得一致性位點,然后開始備份非InnoDB文件(如frm、MYD、MYI、CSV、opt、par等格式的文件),在拷貝非InnoDB文件的過程當中,數據庫處于全局只讀狀態。

對于不支持backup lock的版本,只能通過flush tables with read lock來獲取全局讀鎖,但這樣也同樣會鎖住innodb表,殺傷力太大。所以使用xtrabackup備份Oracle的MySQL,實質上只能實現innodb表的部分時間熱備、部分時間溫備。

對于支持backup lock的版本,xtrabackup通過lock tables for backup獲取輕量級的backup locks來替代flush tables with read lock,因為它只鎖定非innodb表,所以由此實現了innodb表的真正熱備

(6)當innobackup拷貝完所有的非InnoDB文件后,包括獲取二進制日志中一致性位置的坐標點、結束redo log的監控和拷貝、釋放鎖等,會通知xtrabackup,通知完成后,進入等待狀態;

(7)xtrabackup收到innobackupex備份完成的通知后,會停止redo拷貝線程,然后通知innobackupex,redo.log文件拷貝完成;

(8)innobackupex收到redo.log備份完成后,就進行解鎖操作,執行:UNLOCK TABLES;

對于不支持backup lock的版本,收尾階段的過程是這樣的:獲取二進制日志的一致性坐標點、結束redo log的監控和拷貝、釋放鎖。

對于支持backup lock的版本,收尾階段的過程是這樣的:先通過lock binlog for bakcup來獲取二進制日志鎖,然后結束redo log的監控和拷貝,再unlock tables釋放表鎖,隨后獲取二進制日志的一致性位置坐

標點,最后unlock binlog釋放二進制日志鎖。

(9)最后innbackupex和xtrabackup進程各自釋放資源,寫備份元數據信息等,innobackupex等xtrabackup子進程結束后退出。

注:

percona Server 5.6+?支持一種新鎖——backup lock(備份鎖),這種鎖是percona對MySQL的補充,專門為備份而設計。這種鎖在percona Server 5.6+ 有,MariaDB中也有,但是Oracle的MySQL中沒有,至少MySQL 5.7中沒有。

這種鎖用在備份的時候替代?flush tables with read lock?獲取全局鎖,是一種輕量級的全局鎖。它有兩種類型的鎖:備份表鎖和二進制日志鎖。為此新增了3種語法:

1

2

3

lock tablesfor?backup??# 申請備份表鎖

lock binlogfor?backup??# 申請二進制日志鎖

unlock binlog???????????# 釋放二進制日志鎖

備份表鎖在全局范圍內只對非innodb表加鎖,所以持有該鎖后無法修改非innodb表,但卻不影響innodb表的DML。當然,因為是全局鎖,所以也會阻塞DDL操作。

二進制日志鎖在全局范圍內鎖定二進制日志,所以會阻塞其他會話修改二進制日志。這樣可以保證能夠獲取到二進制日志中一致性的位置坐標。

全量備份:

備份開始時首先會開啟一個后臺檢測進程,實時檢測mysql redo的變化,一旦發現redo中有新的日志寫入,立刻將日志記入后臺日志文件xtrabackup_log中。之后復制innodb的數據文件和系統表空間文件ibdata1,待復制結束后,執行flush tables with read lock操作,復制.frm,MYI,MYD,等文件(執行flush tableswith read lock的目的是為了防止數據表發生DDL操作,并且在這一時刻獲得binlog的位置)最后會發出unlock tables,把表設置為可讀可寫狀態,最終停止xtrabackup_log。?

增量備份:?

innobackupex增量備份過程中的"增量"處理,其實主要是相對innodb而言,對myisam和其他存儲引擎而言,它仍然是全拷貝(全備份)

"增量"備份的過程主要是通過拷貝innodb中有變更的"頁"(這些變更的數據頁指的是"頁"的LSN大于xtrabackup_checkpoints中給定的LSN)。增量備份是基于全備的,第一次增備的數據必須要基于上一次的全備,之后的每次增備都是基于上一次的增備,最終達到一致性的增備。增量備份的過程如下,和全備的過程很類似,區別僅在第2步。

全備恢復

這一階段會啟動xtrabackup內嵌的innodb實例,回放xtrabackup日志xtrabackup_log,將提交的事務信息變更應用到innodb數據/表空間,同時回滾未提交的事務(這一過程類似innodb的實例恢復)。

備份的時候拷貝走的數據文件可能是不一致的,比如監控著MySQL的redo log中在拷貝過程完成后又新的事務提交了,而拷貝走的數據是未提交狀態的,那么就需要對該事務前滾;如果監控到的日志中有事務未提交,那么該事務就需要回滾。

但是如果只備份了myisam表或其他非事務表數據,因為備份階段直接鎖定了這些表,所以不會有不一致的狀態。

xtrabackup有一個"準備"的階段。這個階段的實質就是對備份的innodb數據應用redo log,該回滾的回滾,該前滾的前滾,最終保證xtrabackup_logfile中記錄的redo log已經全部應用到備份數據頁上,并且實現了一致性。當應用結束后,會重寫"xtrabackup_logfile"再次保證該redo log和備份的數據是對應的

恢復過程如下圖:

增備恢復?

和全備恢復類似,也需要兩步,一是數據文件的恢復,如圖4,這里的數據來源由3部分組成:全備份,增量備份和xtrabackup log。二是對未提交事務的回滾

  • 四、xtrabackup的安裝部署以及備份恢復實現

  • 1、xtrabackup的安裝

下載地址:https://www.percona.com/downloads/XtraBackup/LATEST/

可以選擇rpm包方式安裝,也可以下載源碼包編譯安裝,這里直接采用rpm包的方式進行安裝

[root@master tools]# wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.9/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm
[root@master tools]# yum install -y percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm 
[root@master ~]# rpm -qa |grep xtrabackup
percona-xtrabackup-24-2.4.9-1.el7.x86_64Xtrabackup中主要包含兩個工具:
xtrabackup:是用于熱備innodb,xtradb表中數據的工具,不能備份其他類型的表,也不能備份數據表結構;
innobackupex:是將xtrabackup進行封裝的perl腳本,提供了備份myisam表的能力。
常用選項:  --host     指定主機--user     指定用戶名--password    指定密碼--port     指定端口--databases     指定數據庫--incremental    創建增量備份--incremental-basedir   指定包含完全備份的目錄--incremental-dir      指定包含增量備份的目錄   --apply-log        對備份進行預處理操作             一般情況下,在備份完成后,數據尚且不能用于恢復操作,因為備份的數據中可能會包含尚未提交的事務或已經提交但尚未同步至數據文件中的事務。因此,此時數據文件仍處理不一致狀態。“準備”的主要作用正是通過回滾未提交的事務及同步已經提交的事務至數據文件也使得數據文件處于一致性狀態。--redo-only      不回滾未提交事務--copy-back     恢復備份目錄裝完xtrabackup后,生成以下幾個工具
[root@localhost bin]# ./xb
xbcloud        xbcloud_osenv  xbcrypt        xbiff          xbrlapi        xbstreamxbcloud和xbcloud_osenv是xtrabackup新的高級特性:云備份;
xbcrypt也是新的特性,加密備份集;
xbstream是xtrabackup的流數據功能,通過流數據功能,可將備份內容打包并傳給管道后的壓縮工具進行壓縮;
xtrabackup是主程序;
innobackupex在以前是一個perl腳本,會調用xtrabackup這個二進制工具,從xtrabackup 2.3開始,該工具使用C語言進行了重寫,當前它是xtabackup二進制工具的一個軟連接,但是實際的使用方法卻不同,并且在以后的版本中會刪除該工具。   

使用innobackupex備份時,其會調用xtrabackup備份所有的InnoDB表,復制所有關于表結構定義的相關文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相關文件,同時還會備份觸發器和數據庫配置信息相關的文件,這些文件會被保存到一個以時間命名的目錄當中。在備份的同時,innobackupex還會在備份目錄中創建如下文件:

(1)xtrabackup_checkpoints -- 備份類型(如完全或增量)、備份狀態(如是否已經為prepared狀態)和LSN(日志序列號)范圍信息:每個InnoDB頁(通常為16k大小)
都會包含一個日志序列號,即LSN,LSN是整個數據庫系統的系統版本號,每個頁面相關的LSN能夠表明此頁面最近是如何發生改變的。(2)xtrabackup_binlog_info  --  mysql服務器當前正在使用的二進制日志文件及備份這一刻位置二進制日志時間的位置。(3)xtrabackup_binlog_pos_innodb  --  二進制日志文件及用于InnoDB或XtraDB表的二進制日志文件的當前position。(4)xtrabackup_binary  --  備份中用到的xtrabackup的可執行文件;(5)backup-my.cnf  --  備份命令用到的配置選項信息:在使用innobackupex進行備份時,還可以使用--no-timestamp選項來阻止命令自動創建一個以時間命名的目錄:如此一來,innobackupex命令將會創建一個BACKUP-DIR目錄來存儲備份數據。

如果要使用一個最小權限的用戶進行備份,則可基于如下命令創建此類用戶:如果要使用一個最小權限的用戶進行備份,則可基于如下命令創建此類用戶:

?

mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY '123456';  #創建用戶
mysql> REVOKE ALL PRIVILEGES,GRANT OPTION FROM 'bkpuser';  #回收此用戶所有權限
mysql> GRANT RELOAD,LOCK TABLES,RELICATION CLIENT ON *.* TO 'bkpuser'@'localhost';  #授權刷新、鎖定表、用戶查看服務器狀態
mysql> FLUSH PRIVILEGES;  #刷新授權表mysql> create user 'backup'@'%' identified by 'yayun';
Query OK, 0 rows affected (0.01 sec)mysql> grant reload,lock tables,replication client,create tablespace,super on *.* to 'backup'@'%';
Query OK, 0 rows affected (0.00 sec)mysql>

?

注意:備份時需啟動MySQL,恢復時需關閉MySQL,清空mysql數據目錄且不能重新初始化,恢復數據后應該立即進行一次完全備份

  • 2、xtrabackup全量備份與恢復

備份:
innobackupex --user=DBUSER --password=DBUSERPASS --defaults-file=/etc/my.cnf /path/to/BACKUP-DIR/恢復:
innobackupex --apply-log /backups/2018-07-30_11-04-55/
innobackupex --copy-back --defaults-file=/etc/my.cnf  /backups/2018-07-30_11-04-55/

?

(1)準備(prepare)一個完全備份

一般情況下,在備份完成后,數據尚且不能用于恢復操作,因為備份的數據中可能會包含尚未提交的事務或者已經提交但尚未同步至數據文件中的事務。因此,此時數據文件仍處于不一致狀態。"準備"的主要作用正是通過回滾未提交的事務及同步已經提交的事務至數據文件也使用得數據文件處于一致性狀態。

innobackupex命令的--apply-log選項可用于實現上述功能,如下面的命令:

# innobackupex --apply-log /path/to/BACKUP-DIR
如果執行正確,其最后輸出的幾行信息通常如下:120407 09:01:04 innobackupex: completed OK!

?在實現"準備"的過程中,innobackupex通常還可以使用--user-memory選項來指定其可以使用的內存的大小,默認為100M.如果有足夠的內存空間可用,可以多劃分一些內存給prepare的過程,以提高其完成備份的速度。

(2)從一個完全備份中恢復數據

注意:恢復不用啟動MySQL

innobackupex命令的--copy-back選項用于恢復操作,其通過復制所有數據相關的文件至mysql服務器DATADIR目錄中來執行恢復過程。innobackupex通過backup-my.cnf來獲取DATADIR目錄的相關信息。

# innobackupex --copy-back /path/to/BACKUP-DIR

當數據恢復至DATADIR目錄以后,還需要確保所有的數據文件的屬主和屬組均為正確的用戶,如mysql,否則,在啟動mysqld之前還需要事先修改數據文件的屬主和屬組。如:

# chown -R mysql.mysql /mydata/data/

(3)實戰練習

(1)全量備份
[root@master backups]# innobackupex --user=root --password=123456 --host=127.0.0.1 /backups/  #在master上進行全庫備份#語法解釋說明:
#--user=root 指定備份用戶
#--password=123456  指定備份用戶密碼
#--host  指定主機
#/backups  指定備份目錄
[root@master backups]# ll
total 0
drwxr-x--- 7 root root 232 Jul 30 11:01 2018-07-30_11-01-37
[root@master backups]# ll 2018-07-30_11-01-37/  #查看備份數據
total 77856
-rw-r----- 1 root root      418 Jul 30 11:01 backup-my.cnf  #備份用到的配置選項信息文件
-rw-r----- 1 root root 79691776 Jul 30 11:01 ibdata1  #數據文件
drwxr-x--- 2 root root       20 Jul 30 11:01 kim
drwxr-x--- 2 root root     4096 Jul 30 11:01 mysql
drwxr-x--- 2 root root     4096 Jul 30 11:01 performance_schema
drwxr-x--- 2 root root       20 Jul 30 11:01 repppp
drwxr-x--- 2 root root     4096 Jul 30 11:01 wordpress
-rw-r----- 1 root root       21 Jul 30 11:01 xtrabackup_binlog_info  #mysql服務器當前正在使用的二進制日志文件和此時二進制日志時間的位置信息文件
-rw-r----- 1 root root      113 Jul 30 11:01 xtrabackup_checkpoints  #備份的類型、狀態和LSN狀態信息文件
-rw-r----- 1 root root      482 Jul 30 11:01 xtrabackup_info
-rw-r----- 1 root root     2560 Jul 30 11:01 xtrabackup_logfile    #備份的日志文件(2)恢復
[root@slave ~]# /etc/init.d/mysqld stop  #停止slave上的mysql
Shutting down MySQL.. SUCCESS! [root@slave tools]# yum install -y percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm   #安裝xtrabackup
[root@master backups]# scp -r 2018-07-30_11-01-37/ root@192.168.56.12:/backups/   #從master上拷貝備份數據
[root@slave tools]# innobackupex --apply-log /backups/2018-07-30_11-01-37/      #合并數據,使數據文件處于一致性的狀態
180729 23:18:23 innobackupex: Starting the apply-log operationIMPORTANT: Please check that the apply-log run completes successfully.At the end of a successful apply-log run innobackupexprints "completed OK!".innobackupex version 2.4.9 based on MySQL server 5.7.13 Linux (x86_64) (revision id: a467167cdd4)
xtrabackup: cd to /backups/2018-07-30_11-01-37/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(3127097)
......
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 3129915
180729 23:18:30 completed OK!
[root@slave ~]# rm -rf /usr/local/mysql/data/  #在slave上刪除原有的數據
[root@slave ~]# vim /etc/my.cnf  #配置my.cnf的數據目錄路徑,否則會報錯,要和master一致
datadir=/usr/local/mysql/data
[root@slave ~]# innobackupex --copy-back /backups/2018-07-30_11-01-37/  #在slave上數據恢復
180729 23:32:03 innobackupex: Starting the copy-back operationIMPORTANT: Please check that the copy-back run completes successfully.At the end of a successful copy-back run innobackupexprints "completed OK!".
......
180729 23:32:08 completed OK!  #看到completed OK就是恢復正常了
[root@slave ~]# ll /usr/local/mysql/data/  #slave上查看數據目錄,可以看到數據已經恢復,但是屬主會有問題,需要進行修改,所以一般使用mysql的運行用戶進行恢復,否則需要進行修改屬主和屬組信息
total 188432
-rw-r----- 1 root root 79691776 Jul 29 23:32 ibdata1
-rw-r----- 1 root root 50331648 Jul 29 23:32 ib_logfile0
-rw-r----- 1 root root 50331648 Jul 29 23:32 ib_logfile1
-rw-r----- 1 root root 12582912 Jul 29 23:32 ibtmp1
drwxr-x--- 2 root root       20 Jul 29 23:32 kim
drwxr-x--- 2 root root     4096 Jul 29 23:32 mysql
drwxr-x--- 2 root root     4096 Jul 29 23:32 performance_schema
drwxr-x--- 2 root root       20 Jul 29 23:32 repppp
drwxr-x--- 2 root root     4096 Jul 29 23:32 wordpress
-rw-r----- 1 root root      482 Jul 29 23:32 xtrabackup_info
[root@slave ~]# chown -R mysql.mysql /usr/local/mysql/data/  #修改屬主屬組
[root@slave ~]# /etc/init.d/mysqld start  #啟動mysql
Starting MySQL. SUCCESS! 
[root@slave ~]# mysql -uroot -p -e "show databases;"  #查看數據,是否恢復
Enter password: 
+--------------------+
| Database           |
+--------------------+
| information_schema |
| kim                |
| mysql              |
| performance_schema |
| repppp             |
| wordpress          |
+--------------------+

總結全庫備份與恢復三步曲:

a. innobackupex全量備份,并指定備份目錄路徑;

b. 在恢復前,需要使用--apply-log參數先進行合并數據文件,確保數據的一致性要求;

c. 恢復時,直接使用--copy-back參數進行恢復,需要注意的是,在my.cnf中要指定數據文件目錄的路徑。

  • 3、xtrabackup增量備份與恢復

  使用innobackupex進行增量備份,每個InnoDB的頁面都會包含一個LSN信息,每當相關的數據發生改變,相關的頁面的LSN就會自動增長。這正是InnoDB表可以進行增量備份的基礎,即innobackupex通過備份上次完全備份之后發生改變的頁面來實現。在進行增量備份時,首先要進行一次全量備份,第一次增量備份是基于全備的,之后的增量備份都是基于上一次的增量備份的,以此類推。

要實現第一次增量備份,可以使用下面的命令進行:

基于全量備份的增量備份與恢復
做一次增量備份(基于當前最新的全量備份)
innobackupex --user=root --password=root --defaults-file=/etc/my.cnf --incremental /backups/ --incremental-basedir=/backups/2018-07-30_11-01-37
1. 準備基于全量
innobackupex --user=root --password=root --defaults-file=/etc/my.cnf --apply-log --redo-only /backups/2018-07-30_11-01-37
2. 準備基于增量
innobackupex --user=root --password=root --defaults-file=/etc/my.cnf --apply-log --redo-only /backups/2018-07-30_11-01-37 --incremental-dir=/backups/2018-07-30_13-51-47/
3. 恢復
innobackupex --copy-back --defaults-file=/etc/my.cnf /opt/2017-01-05_11-04-55/
解釋:
1. 2018-07-30_11-01-37指的是完全備份所在的目錄。
2. 2018-07-30_13-51-47指定是第一次基于2018-07-30_11-01-37增量備份的目錄,其他類似以此類推,即如果有多次增量備份。每一次都要執行如上操作。

需要注意的是,增量備份僅能應用于InnoDB或XtraDB表,對于MyISAM表而言,執行增量備份時其實進行的是完全備份。

"準備"(prepare)增量備份與整理完全備份有著一些不同,尤其要注意的是:
①需要在每個備份 (包括完全和各個增量備份)上,將已經提交的事務進行"重放"。"重放"之后,所有的備份數據將合并到完全備份上。
②基于所有的備份將未提交的事務進行"回滾"

(1)增量備份演示

[root@master backups]# innobackupex --user=root --password=123456 --host=127.0.0.1 /backups/   #全備數據
[root@master ~]# mysql -uroot -p  #在master上創建student庫并創建testtb表插入若干數據
Enter password: 
mysql> create database student;
Query OK, 1 row affected (0.03 sec)mysql> use student;
Database changed
mysql> create table testtb(id int);
Query OK, 0 rows affected (0.07 sec)mysql> insert into testtb values(1),(10),(99);
Query OK, 3 rows affected (0.04 sec)
Records: 3  Duplicates: 0  Warnings: 0mysql> select * from testtb;
+------+
| id   |
+------+
|    1 |
|   10 |
|   99 |
+------+
3 rows in set (0.00 sec)mysql> quit;
Bye#使用innobackupex進行增量備份
[root@master backups]# innobackupex --user=root --password=123456 --host=127.0.0.1 --incremental /backups/ --incremental-basedir=/backups/2018-07-30_11-01-37/
......
180730 13:51:50 Executing UNLOCK TABLES
180730 13:51:50 All tables unlocked
180730 13:51:50 Backup created in directory '/backups/2018-07-30_13-51-47/'
MySQL binlog position: filename 'mysql-bin.000005', position '664'
180730 13:51:50 [00] Writing /backups/2018-07-30_13-51-47/backup-my.cnf
180730 13:51:50 [00]        ...done
180730 13:51:50 [00] Writing /backups/2018-07-30_13-51-47/xtrabackup_info
180730 13:51:50 [00]        ...done
xtrabackup: Transaction log of lsn (3158741) to (3158741) was copied.
180730 13:51:50 completed OK!
[root@master backups]# ll  #查看備份數據
total 0
drwxr-x--- 7 root root 232 Jul 30 11:01 2018-07-30_11-01-37  #全量備份數據目錄
drwxr-x--- 8 root root 273 Jul 30 13:51 2018-07-30_13-51-47  #增量備份數據目錄
[root@master 2018-07-30_11-01-37]# cat xtrabackup_checkpoints #查看全量備份的xtrabackup_checkpoints
backup_type = full-backuped  #備份類型為全量備份
from_lsn = 0  #lsn從0開始
to_lsn = 3127097  #lsn到3127097結束
last_lsn = 3127097
compact = 0
recover_binlog_info = 0[root@master 2018-07-30_13-51-47]# cat xtrabackup_checkpoints   #查看增量備份的xtrabackup_checkpoints
backup_type = incremental  #備份類型為增量備份
from_lsn = 3127097  #lsn從3127097開始
to_lsn = 3158741    #lsn到啊3158741結束
last_lsn = 3158741  
compact = 0
recover_binlog_info = 0

(2)增量備份后數據恢復演示

(1)模擬mysql故障,刪除數據目錄所有數據
[root@master ~]# /etc/init.d/mysqld stop  #模擬mysql故障,停止mysql
Shutting down MySQL.. SUCCESS! 
[root@master ~]# rm -rf /usr/local/mysql/data/*  #刪除數據目錄中的所有數據(2)合并全備數據目錄,確保數據的一致性
[root@master ~]# innobackupex --apply-log --redo-only /backups/2018-07-30_11-01-37/
180730 14:05:27 innobackupex: Starting the apply-log operationIMPORTANT: Please check that the apply-log run completes successfully.At the end of a successful apply-log run innobackupexprints "completed OK!".innobackupex version 2.4.9 based on MySQL server 5.7.13 Linux (x86_64) (revision id: a467167cdd4)
xtrabackup: cd to /backups/2018-07-30_11-01-37/
......
......
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 3127106
InnoDB: Number of pools: 1
180730 14:05:29 completed OK!(3)將增量備份數據合并到全備數據目錄當中
[root@master ~]# innobackupex --apply-log --redo-only /backups/2018-07-30_11-01-37/ --incremental-dir=/backups/2018-07-30_13-51-47/
180730 14:06:42 innobackupex: Starting the apply-log operationIMPORTANT: Please check that the apply-log run completes successfully.At the end of a successful apply-log run innobackupexprints "completed OK!".
......
......
180730 14:06:44 [00]        ...done
180730 14:06:44 completed OK!
[root@master ~]# cat /backups/2018-07-30_11-01-37/xtrabackup_checkpoints 
backup_type = log-applied  #查看到數據備份類型是增加
from_lsn = 0  #lsn從0開始
to_lsn = 3158741  #lsn結束號為最新的lsn
last_lsn = 3158741
compact = 0
recover_binlog_info = 0(4)恢復數據
[root@master ~]# innobackupex --copy-back /backups/2018-07-30_11-01-37/
180730 14:07:51 innobackupex: Starting the copy-back operationIMPORTANT: Please check that the copy-back run completes successfully.At the end of a successful copy-back run innobackupexprints "completed OK!".
.......
.......
180730 14:08:17 [01]        ...done
180730 14:08:17 completed OK!
[root@master ~]# ll /usr/local/mysql/data/
total 77844
-rw-r----- 1 root root 79691776 Jul 30 14:08 ibdata1
drwxr-x--- 2 root root       20 Jul 30 14:08 kim
drwxr-x--- 2 root root     4096 Jul 30 14:08 mysql
drwxr-x--- 2 root root     4096 Jul 30 14:08 performance_schema
drwxr-x--- 2 root root       20 Jul 30 14:08 repppp
drwxr-x--- 2 root root       56 Jul 30 14:08 student
drwxr-x--- 2 root root     4096 Jul 30 14:08 wordpress
-rw-r----- 1 root root       21 Jul 30 14:08 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root      554 Jul 30 14:08 xtrabackup_info
[root@master ~]# chown -R mysql.mysql /usr/local/mysql/data  #更改數據的屬主屬組
[root@master ~]# /etc/init.d/mysqld start  #啟動mysql
Starting MySQL.Logging to '/usr/local/mysql/data/master.err'.
.. SUCCESS! 
[root@master ~]# mysql -uroot -p -e "show databases;"  #查看數據是否恢復
Enter password: 
+--------------------+
| Database           |
+--------------------+
| information_schema |
| kim                |
| mysql              |
| performance_schema |
| repppp             |
| student            |
| wordpress          |
+--------------------+

?

總結:

(1)增量備份需要使用參數--incremental指定需要備份到哪個目錄,使用incremental-dir指定全備目錄;

(2)進行數據備份時,需要使用參數--apply-log redo-only先合并全備數據目錄數據,確保全備數據目錄數據的一致性;

(3)再將增量備份數據使用參數--incremental-dir合并到全備數據當中;

(4)最后通過最后的全備數據進行恢復數據,注意,如果有多個增量備份,需要逐一合并到全備數據當中,再進行恢復。

增量備份的恢復大體為3個步驟

*恢復完全備份

*恢復增量備份到完全備份(開始恢復的增量備份要添加--redo-only參數,到最后一次增量備份去掉--redo-only參數)

*對整體的完全備份進行恢復,回滾那些未提交的數據

# 使用tar流
innobackupex --user=root --password=123456 --stream=tar /bakdir/ >/tmp/a.tar
# 使用tar流的同時交給gzip壓縮
innobackupex --user=root --password=123456 --stream=tar /bakdir/ | gzip >/tmp/a.tar.gz
# 使用tar流備份到遠程主機中并歸檔
innobackupex --user=root --password=123456 --stream=tar /bakdir/ | ssh root@192.168.100.10  "cat -  > /tmp/`date +%F_%H-%M-%S`.tar"
# 使用tar流備份到原遠程主機中并解包
innobackupex --user=root --password=123456 --stream=tar /bakdir/ | ssh root@192.168.100.10  "cat -  | tar -x -C /tmp/"# 使用xtrabackup自帶的xbstream流
innobackupex --user=root --password=123456 --stream=xbstream /bakdir/ >/tmp/b.xbs
# 解壓xbstream流
innobackupex --user=root --password=123456 --stream=xbstream /bakdir/ | ssh root@192.168.100.10  "cat -  | xbstream -x -C /tmp/"
# 使用xbstream流的同時進行壓縮,使用"--compress"選項
innobackupex --user=root --password=123456 --stream=xbstream --compress /bakdir/ > /bakdir/backup.xbs

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/535371.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/535371.shtml
英文地址,請注明出處:http://en.pswp.cn/news/535371.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

實時備份工具之inotify+rsync

1.inotify簡介 inotify 是一個從 2.6.13 內核開始,對 Linux 文件系統進行高效率、細粒度、異步地監控機制, 用于通知用戶空間程序的文件系統變化。可利用它對用戶空間進行安全、性能、以及其他方面的監控。Inotify 反應靈敏,用法非常簡單&…

nginx proxy_cache緩存詳解

目錄 1. 關于緩沖區指令 1.1 proxy_buffer_size1.2 proxy_buffering1.3 proxy_buffers1.4 proxy_busy_buffers_size1.5 proxy_max_temp_file_size1.6 proxy_temp_file_write_size1.7 緩沖區配置實例2. 常用配置項 2.1 proxy_cache_path2.2 proxy_temp_path2.3 proxy_cache2.4 …

mysql主從延遲

在實際的生產環境中,由單臺MySQL作為獨立的數據庫是完全不能滿足實際需求的,無論是在安全性,高可用性以及高并發等各個方面 因此,一般來說都是通過集群主從復制(Master-Slave)的方式來同步數據&#xff0c…

16張圖帶你吃透高性能 Redis 集群

現如今 Redis 變得越來越流行,幾乎在很多項目中都要被用到,不知道你在使用 Redis 時,有沒有思考過,Redis 到底是如何穩定、高性能地提供服務的? 你也可以嘗試回答一下以下這些問題: 我使用 Redis 的場景很…

Redis與MySQL雙寫一致性如何保證

談談一致性 一致性就是數據保持一致,在分布式系統中,可以理解為多個節點中數據的值是一致的。 強一致性:這種一致性級別是最符合用戶直覺的,它要求系統寫入什么,讀出來的也會是什么,用戶體驗好,…

weblogic忘記console密碼

進入 cd /sotware/oracle_ldap/Middleware/user_projects/domains/base_domain/security/ 目錄 執行 java -classpath /sotware/oracle_ldap/Middleware/wlserver_10.3/server/lib/weblogic.jar weblogic.security.utils.AdminAccount weblogic(賬號) weblogic123(密碼) . …

Mysql高性能優化技能總結

數據庫命令規范 所有數據庫對象名稱必須使用小寫字母并用下劃線分割 所有數據庫對象名稱禁止使用mysql保留關鍵字(如果表名中包含關鍵字查詢時,需要將其用單引號括起來) 數據庫對象的命名要能做到見名識意,并且最后不要超過32個…

Redis的AOF日志

如果 Redis 每執行一條寫操作命令,就把該命令以追加的方式寫入到一個文件里,然后重啟 Redis 的時候,先去讀取這個文件里的命令,并且執行它,這不就相當于恢復了緩存數據了嗎? 這種保存寫操作命令到日志的持久…

Redis 核心技術與實戰

目錄 開篇詞 | 這樣學 Redis,才能技高一籌 01 | 基本架構:一個鍵值數據庫包含什么? 02 | 數據結構:快速的Redis有哪些慢操作? 鍵和值用什么結構組織? 為什么哈希表操作變慢了? 有哪些底層數…

redis核心技術與實戰(二)緩存應用篇

1.《旁路緩存:redis 在緩存中工作原理》 1.緩存的兩個特征 1.什么是緩存,有什么特征? 磁盤->內存->cpu 之間讀寫速度差異巨大,為了平衡他們之間的差異,操作系統默認使用了兩種緩存; CPU 里面的末級…

redis核心技術與實戰(三) 性能篇

影響redis性能主要有以下部分: Redis 內部的阻塞式操作; CPU核和NUMA架構 Redis關鍵系統配置 Redis內存碎片 Redis緩沖區 下面一個個來介紹這些地方 1.《redis 有哪些阻塞點?》 redis實例主要交互的對象有以下幾點,我們依據下面這…

redis核心與實戰(一)數據結構篇

1.《redis數據結構概覽》 1.數據結構概覽 數據模型:一共5種,String(字符串)、List(列表)、Hash(哈希)、Set(集合)和 Sorted Set(有序集合&#xf…

redis核心技術與實戰(四)高可用高擴展篇

1.《redis架構組成》 1.redis學習維度 2.一個基本的鍵值型數據庫包括什么? 1.訪問框架 redis通過網絡框架進行訪問,使得 Redis 可以作為一個基礎性的網絡服務進行訪問,擴大了redis應用范圍; 過程:如果客戶端發送“pu…

tomcat監控腳本

#!/bin/sh# func:自動監控tomcat腳本并且執行重啟操作# 獲取tomcat進程ID(其中[grep -w .....]中的.....需要替換為實際部署的tomcat文件夾名,如下) TomcatID$(ps -ef |grep tomcat |grep -w /usr/local/tomcat/apache-tomcat-8.5.31|grep -v…

weblogic命令行操作

啟動和停止子節點: [rootoud bin]# cd /sotware/oracle_ldap/Middleware/user_projects/domains/base_domain/bin/ [rootoud bin]# ./startManagedWebLogic.sh Server-0 http://192.168.63.129:7001 -Dweblogic.management.usernameweblogic -Dweblogic.management…

Ansible系列--Copy模塊

copy模塊 copy模塊在ansible里的角色就是把ansible執行機器上的文件拷貝到遠程節點上。 與fetch模塊相反的操作 常用參數 參數名是否必須默認值選項說明srcno 用于定位ansible執行的機器上的文件,需要絕對路徑。如果拷貝的是文件夾,那么文件夾會整體…

ANSIBLE--handlers的概念

handlers可以理解成另一種tasks,handlers是另一種’任務列表’,handlers中的任務會被tasks中的任務進行”調用”,但是,被”調用”并不意味著一定會執行,只有當tasks中的任務”真正執行”以后(真正的進行實際…

ansible--- tags

tags可以幫助我們對任務進行’打標簽’的操作,當任務存在標簽以后,我們就可以在執行playbook時,借助標簽,指定執行哪些任務,或者指定不執行哪些任務。在實際的使用中,我們應該讓tags的值能夠見名知義。 當…

ANSIBLE---變量

注冊變量 ansible的模塊在運行之后,其實都會返回一些”返回值”,只是默認情況下,這些”返回值”并不會顯示而已,我們可以把這些返回值寫入到某個變量中,這樣我們就能夠通過引用對應的變量從而獲取到這些返回值了&…

inux中限制用戶進程CPU和內存占用率

#!/bin/sh PIDStop -bn 1 | grep "^ *[1-9]" | awk { if($9 > 50 || $10 > 25 && id -u $2 > 500) print $1} echo $PIDS for PID in $PIDS dorenice 10 $PIDecho "renice 10 $PID" done