基於Xtrabackup備份mysql(MairaDB)

1、Xtrabackup
mysql

一、Xtrabackup介紹sql

   Percona XtraBackup是開源免費的MySQL數據庫熱備份軟件,它能對InnoDB和XtraDB存儲引擎的數據庫非阻塞地備份,據官方介紹,這也是世界上唯一一款開源的可以對innodb和xtradb數據庫進行熱備的工具數據庫

二、Xtrabackup的特色vim

(1)在線熱備整個庫的InnoDB、XtraDB表bash

(2)備份過程不會打斷正在執行的事務;服務器

(3)在xtrabackup的上一次整庫備份基礎上作增量備份(innodb only)app

(4)自動實現備份檢驗;ide

(5)以流的形式產生備份,能夠直接保存到遠程主機上工具

三、Xtrabackup有兩個主要的工具ui

(1)xtrabackup

   xtrabackup的增量備份只能備份InnoDB和XtraDB兩種數據表,而不能備份MyISAM數據表

(2)innobackupex

   innobackupex是參考了InnoDB Hotbackup的innoback腳本修改而來的.innobackupex是一個perl腳本封裝,封裝了xtrabackup。主要是爲了方便的同時備份InnoDB和MyISAM引擎的表,但在處理myisam時須要加一個讀鎖。而且加入了一些使用的選項。如slave-info能夠記錄備份恢復後,做爲slave須要的一些信息,根據這些信息,能夠很方便的利用備份來重作slave。

四、增量備份的過程

(1)首先完成一個徹底備份,並記錄下此時檢查點的LSN(Log Sequence Number)。

(2)在進程增量備份時,比較表空間中每一個頁的LSN是否大於上次備份時的LSN,若是是,則備份該頁,同時記錄當前檢查點的LSN。

  首先,在logfile中找到並記錄最後一個checkpoint(「last checkpoint LSN」),而後開始從LSN的位置開始拷貝InnoDB的logfile到xtrabackup_logfile;接着,開始拷貝所有的數據文件.ibd;在拷貝所有數據文件結束以後,才中止拷貝logfile。

  由於logfile裏面記錄所有的數據修改狀況,因此,即便在備份過程當中數據文件被修改過了,恢復時仍然可以經過解析xtrabackup_logfile保持數據的一致。

五、Xtrabackup備份原理

(1)XtraBackup基於InnoDB的crash-recovery功能。它會複製innodb的data file,因爲不鎖表,複製出來的數據是不一致的,在恢復的時候使用crash-recovery,使得數據恢復一致。

(2)InnoDB維護了一個redo log,又稱爲transaction log,事務日誌,它包含了innodb數據的全部改動狀況。當InnoDB啓動的時候,它會先去檢查data file和transaction log,而且會作二步操做:

  ①、XtraBackup在備份的時候, 一頁一頁地複製innodb的數據,並且不鎖定表,與此同時,XtraBackup還有另一個線程監視着transactions log,一旦log發生變化,就把變化過的log pages複製走。爲何要急着複製走呢? 由於transactions log文件大小有限,寫滿以後,就會從頭再開始寫,因此新數據可能會覆蓋到舊的數據。

  ②、在prepare過程當中,XtraBackup使用複製到的transactions log對備份出來的innodb data file進行crash recovery。

六、實現細節

   XtraBackup以read-write模式打開innodb的數據文件,而後對其進行復制。其實它不會修改此文件。也就是說,運行XtraBackup的用戶,必須對innodb的數據文件具備讀寫權限。之因此採用read-write模式是由於XtraBackup採用了其內置的innodb庫來打開文件,而innodb庫打開文件的時候就是rw的。

七、Xtrabackup的安裝

(1)所需軟件,直接到percona官網下載便可

percona-toolkit-2.2.4-1.noarch.rpm
percona-xtrabackup-2.1.8-733.rhel6.x86_64.rpm

由於percona-toolkit是perl組件,因此會依賴不少perl庫,因此選擇yum方式安裝

2、Xtrabackup徹底備份的實現

一、前提準備

(1)建立數據備份目錄

[root@shuishui ~]# mkdir /backups/

(2)修改二進制日誌文件存儲路徑

[root@shuishui ~]# vim /etc/my.cnf
log-bin=/mydata/binlogs/master-bin

(3)受權一個最小權限的用戶進行復制

MariaDB [(none)]> grant reload,lock tables,replication client on *.* to 'backup'@'localhost' identified by 'backup';
MariaDB [(none)]> flush privileges;

二、完整備份的實現

(1)導入一個數據庫,就不本身建庫了

MariaDB [hellodb]> set sql_log_bin=0; #導入數據庫過程無需記錄二進制日誌,把以先暫時關閉
MariaDB [hellodb]> source hellodb.sql;
MariaDB [hellodb]> show databases;
+--------------------+
| Database           |
+--------------------+
| hellodb            |
| information_schema |
| makingware         |
| mysql              |
| performance_schema |
| test               |
| ultrax             |
+--------------------+
MariaDB [hellodb]> set sql_log_bin=1; #開啓二進制日誌

(2)作完整備份

[root@shuishui ~]# innobackupex --user=backup --password=backup --host=localhost /backups/   #作完備
……
……
innobackupex: Backup created in directory '/backups/2014-04-21_11-28-06'  #備份存儲路徑
innobackupex: MySQL binlog position: filename 'master-bin.000013', position 105544  #二進制日誌及位置信息
140421 11:28:15  innobackupex: Connection to database server closed
140421 11:28:15  innobackupex: completed OK!  #只有到了這裏才說明備份成功

 看一下備份目錄中生成的一些文件

[root@shuishui ~]# cd /backups/2014-04-21_11-28-06/
[root@shuishui 2014-04-21_11-28-06]# ll
total 12388
-rw-r--r--. 1 root root      357 Apr 21 11:28 backup-my.cnf
drwxr-xr-x. 2 root root     4096 Apr 21 11:28 hellodb
-rw-r-----. 1 root root 12582912 Apr 21 11:28 ibdata1
drwxr-xr-x. 2 root root     4096 Apr 21 11:28 makingware
drwx------. 2 root root     4096 Apr 21 11:28 mysql
drwxr-xr-x. 2 root root     4096 Apr 21 11:28 performance_schema
drwxr-xr-x. 2 root root     4096 Apr 21 11:28 test
drwxr-xr-x. 2 root root    61440 Apr 21 11:28 ultrax
-rw-r--r--. 1 root root       13 Apr 21 11:28 xtrabackup_binary
-rw-r--r--. 1 root root       27 Apr 21 11:28 xtrabackup_binlog_info
-rw-r-----. 1 root root       89 Apr 21 11:28 xtrabackup_checkpoints
-rw-r-----. 1 root root     2560 Apr 21 11:28 xtrabackup_logfile
[root@shuishui 2014-04-21_11-28-06]#

使用innobakupex備份時,其會調用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目錄來存儲備份數據。

3、使用徹底備份恢復數據

一、模擬數據誤刪除

[root@shuishui ~]# rm -rf /mydata/data/*

二、準備一個徹底備份

   通常狀況下,在備份完成後,數據尚且不能用於恢復操做,由於備份的數據中可能會包含還沒有提交的事務或已經提交但還沒有同步至數據文件中的事務。所以,此時數據文件仍處理不一致狀態。「準備」的主要做用正是經過回滾未提交的事務及同步已經提交的事務至數據文件也使得數據文件處於一致性狀態。

   innobackupex命令的--apply-log選項可用於實現上述功能

在實現「準備」的過程當中,innobackupex一般還可使用--use-memory選項來指定其可使用的內存的大小,默認一般爲100M。若是有足夠的內存可用,能夠多劃分一些內存給prepare的過程,以提升其完成速度。

[root@shuishui ~]# innobackupex --apply-log /backups/2014-04-21_11-28-06/
……
……
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 1619478
140421 12:33:26  innobackupex: completed OK!   #準備OK

注意:不要在備份完成後整理,要在恢復時再去整理

三、從徹底備份中恢復數據

   在此時恢復數據時,不要啓動mysql

   innobackupex命令的--copy-back選項用於執行恢復操做,其經過複製全部數據相關的文件至mysql服務器DATADIR目錄中來執行恢復過程。innobackupex經過backup-my.cnf來獲取DATADIR目錄的相關信息。

[root@shuishui ~]# innobackupex --copy-back /backups/2014-04-21_11-28-06/
……
……
140421 12:40:41  innobackupex: completed OK!   #到了這裏就說明恢復成功了

 查看下數據目錄

[root@shuishui ~]# ll /mydata/data/
total 110676
drwxr-xr-x. 2 root root     4096 Apr 21 12:40 hellodb
-rw-r--r--. 1 root root 12582912 Apr 21 12:40 ibdata1
-rw-r--r--. 1 root root 50331648 Apr 21 12:40 ib_logfile0
-rw-r--r--. 1 root root 50331648 Apr 21 12:40 ib_logfile1
drwxr-xr-x. 2 root root     4096 Apr 21 12:40 makingware
drwxr-xr-x. 2 root root     4096 Apr 21 12:40 mysql
drwxr-xr-x. 2 root root     4096 Apr 21 12:40 performance_schema
drwxr-xr-x. 2 root root     4096 Apr 21 12:40 test
drwxr-xr-x. 2 root root    61440 Apr 21 12:40 ultrax

數據是都回來了,但是數據的屬主和屬組都是root,因此應該將其所有修改成mysql

[root@shuishui ~]# chown -R mysql.mysql /mydata/data/
[root@shuishui ~]# ll /mydata/data/
total 110676
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 12:40 hellodb
-rw-r--r--. 1 mysql mysql 12582912 Apr 21 12:40 ibdata1
-rw-r--r--. 1 mysql mysql 50331648 Apr 21 12:40 ib_logfile0
-rw-r--r--. 1 mysql mysql 50331648 Apr 21 12:40 ib_logfile1
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 12:40 makingware
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 12:40 mysql
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 12:40 performance_schema
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 12:40 test
drwxr-xr-x. 2 mysql mysql    61440 Apr 21 12:40 ultrax

啓動mysql服務,連入mysql驗證是否正常

[root@shuishui ~]# service mysqld start
Starting MySQL                                             [  OK  ]
[root@shuishui ~]# mysql
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| hellodb            |
| information_schema |
| makingware         |
| mysql              |
| performance_schema |
| test               |
| ultrax             |
+--------------------+

一個不差,數據完美恢復成功

4、使用innobackupex進行增量備份

   每一個InnoDB的頁面都會包含一個LSN信息,每當相關的數據發生改變,相關的頁面的LSN就會自動增加。這正是InnoDB表能夠進行增量備份的基礎,即innobackupex經過備份上次徹底備份以後發生改變的頁面來實現。

   須要注意的是,增量備份僅能應用於InnoDB或XtraDB表,對於MyISAM表而言,執行增量備份時其實進行的是徹底備份。

一、新建一個數據庫,達到數據庫發生變化的目的

MariaDB [(none)]> create database hlbrc;
Query OK, 1 row affected (0.01 sec)
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| hellodb            |
| hlbrc              |
| information_schema |
| makingware         |
| mysql              |
| performance_schema |
| test               |
| ultrax             |
+--------------------+

二、進行第一次增量備份

[root@shuishui backups]# innobackupex --incremental /backups/ --incremental-basedir=/backups/2014-04-21_11-28-06/
……
……
innobackupex: Backup created in directory '/backups/2014-04-21_13-11-33'  #增量備份也產生了一個以時間命名的目錄
innobackupex: MySQL binlog position: filename 'master-bin.000013', position 105667      #記錄的二進制日誌及位置
140421 13:11:43  innobackupex: Connection to database server closed
140421 13:11:43  innobackupex: completed OK!   #出現OK說明操做成功

   其中,/backups/2014-04-21_11-28-06/指的是徹底備份所在的目錄,此命令執行結束後,innobackupex命令會在/backups目錄中建立一個新的以時間命名的目錄以存放全部的增量備份數據。另外,在執行過增量備份以後再一次進行增量備份時,其--incremental-basedir應該指向上一次的增量備份所在的目錄。

若是每一次都相對於上次的徹底備份作增量備份,那就是差別備份!

既然徹底備份出來的目錄是以日期+時間爲命名的,而增量備份也是日期+時間命名的,那應該怎麼區分這個備份出來的數據目錄是徹底備份仍是增量備份呢

   其實也不少簡單,只需進入備份出來的目錄看一下它的xtrabackup_checkpoints就知道了

[root@shuishui ~]# cd /backups/
[root@shuishui backups]# ls
2014-04-21_11-28-06  2014-04-21_13-11-33
[root@shuishui backups]# cd 2014-04-21_11-28-06/
[root@shuishui 2014-04-21_11-28-06]# ls
backup-my.cnf  ib_logfile0  mysql               ultrax                  xtrabackup_checkpoints
hellodb        ib_logfile1  performance_schema  xtrabackup_binary       xtrabackup_logfile
ibdata1        makingware   test                xtrabackup_binlog_info
[root@shuishui 2014-04-21_11-28-06]# cat xtrabackup_checkpoints  #cat一個這個
backup_type = full-prepared  #這就是徹底備份
from_lsn = 0
to_lsn = 1619228
last_lsn = 1619228
compact = 0

那再看一下剛纔備份出來的那個增量備份的目錄中的xtrabackup_checkpoints

[root@shuishui 2014-04-21_13-11-33]# cat xtrabackup_checkpoints
backup_type = incremental     #這就是增量備份
from_lsn = 1619228
to_lsn = 1619488
last_lsn = 1619488
compact = 0

三、第二次增量備份

   首先再建立一個數據庫,再讓數據庫變化下

MariaDB [(none)]> create database bynr;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| bynr               |        #第二次增量備份時備份了bynr這個庫
| hellodb            |
| hlbrc              |        #第一次增量備份時備份了hlbrc這個庫
| information_schema |
| makingware         |
| mysql              |
| performance_schema |
| test               |
| ultrax             |
+--------------------+

   基於上一次增量備份再作增量備份(增量不就是這樣嗎?不是差別啊!)

[root@shuishui ~]# innobackupex --incremental /backups/ --incremental-basedir=/backups/2014-04-21_13-11-33/  #指的目錄是上一次增量備份的目錄哦
    ……
    ……
innobackupex: Backup created in directory '/backups/2014-04-21_13-36-36'
innobackupex: MySQL binlog position: filename 'master-bin.000013', position 105788
140421 13:36:45  innobackupex: Connection to database server closed
140421 13:36:45  innobackupex: completed OK!   #看到OK才放心

   第二次增量備份後又修改了數據庫,但此時修改完後還沒來得及作增量備份。像這樣的狀況,若是數據丟失了,在沒作增量備份的狀況下,就只能依靠二進制日誌文件來恢復了

MariaDB [(none)]> create database hhht;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| bynr               |        #第二次增量備份時,備份到了bynr這個庫
| hellodb            |
| hhht               |        #第二次增量備份後,建立了hhht這個庫,還沒作增量備份
| hlbrc              |        #第一次增量備份時,備份到了hlbrc這個庫
| information_schema |
| makingware         |
| mysql              |
| performance_schema |
| test               |
| ultrax             |
+--------------------+

5、增量備份的還原

   像準備徹底備份同樣, 增量備份的還原也須要有一個準備的過程

   「準備」(prepare)增量備份與整理徹底備份有着一些不一樣,尤爲要注意的是:

(1)須要在每一個備份(包括徹底和各個增量備份)上,將已經提交的事務進行「重放」。「重放」以後,全部的備份數據將合併到徹底備份上。

(2)基於全部的備份將未提交的事務進行「回滾」。

   因而,操做就變成了:

#innobackupex --apply-log --redo-only BASE-DIR

   接着執行:

# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1

   然後是第二個增量:

# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2

   其中BASE-DIR指的是徹底備份所在的目錄,

   而INCREMENTAL-DIR-1指的是第一次增量備份的目錄,

   INCREMENTAL-DIR-2指的是第二次增量備份的目錄,其它依次類推,即若是有屢次增量備份,每一次都要執行如上操做;

一、刪除數據目錄下的全部文件

[root@shuishui ~]# rm -rf /mydata/data/*    #刪除數據目錄下的全部
[root@shuishui ~]# ls /mydata/data/         #清空的很完全
[root@shuishui ~]# ls /mydata/binlogs/      #還好有二進制日誌,這就是二進制日誌爲何要與數據目錄分開放的緣由,能夠作即時點還原
master-bin.000001  master-bin.000005  master-bin.000009  master-bin.000013
master-bin.000002  master-bin.000006  master-bin.000010  master-bin.000014
master-bin.000003  master-bin.000007  master-bin.000011  master-bin.index
master-bin.000004  master-bin.000008  master-bin.000012  master-bin.state

二、數據還原準備過程

   如今備份目錄中的狀況是這樣的,第一個文件夾是徹底備份,剩下的那兩個是增量備份

[root@shuishui ~]# cd /backups/
[root@shuishui backups]# ls
2014-04-21_11-28-06  2014-04-21_13-11-33  2014-04-21_13-36-36

(1)準備第一次徹底備份

[root@shuishui backups]# ls
2014-04-21_11-28-06  2014-04-21_13-11-33  2014-04-21_13-36-36
[root@shuishui backups]#
[root@shuishui backups]#
[root@shuishui backups]# innobackupex --apply-log --redo-only 2014-04-21_11-28-06/    #準備徹底備份
    ……
    ……
InnoDB: Shutdown completed; log sequence number 1619478
140421 14:27:02  innobackupex: completed OK!   #徹底備份準備OK


(2)準備第一次增量備份

[root@shuishui backups]# ls
2014-04-21_11-28-06  2014-04-21_13-11-33  2014-04-21_13-36-36
[root@shuishui backups]# innobackupex --apply-log --redo-only /backups/2014-04-21_11-28-06/ --incremental-dir=/backups/2014-04-21_13-11-33/
    ……
    ……
innobackupex: Copying '/backups/2014-04-21_13-11-33/hellodb/courses.MYI' to '/backups/2014-04-21_11-28-06/hellodb/courses.MYI'
140421 14:45:01  innobackupex: completed OK!  #準備第一次增量備份OK

(3)準備第二次增量備份

[root@shuishui backups]# ls
2014-04-21_11-28-06  2014-04-21_13-11-33  2014-04-21_13-36-36
[root@shuishui backups]# innobackupex --apply-log --redo-only /backups/2014-04-21_11-28-06/ --incremental-dir=/backups/2014-04-21_13-36-36/
innobackupex: Copying '/backups/2014-04-21_13-36-36/hellodb/courses.MYI' to '/backups/2014-04-21_11-28-06/hellodb/courses.MYI'
140421 14:50:06  innobackupex: completed OK!    #第二次增量備份準備OK

三、還原數據

(1)通過上面的三步準備,如今終於能夠還原數據了,下面就是見證奇蹟的時刻

[root@shuishui 2014-04-21_11-28-06]# cd ..
[root@shuishui backups]# ls
2014-04-21_11-28-06  2014-04-21_13-11-33  2014-04-21_13-36-36
[root@shuishui backups]# innobackupex --copy-back /backups/2014-04-21_11-28-06/    #用準備好的徹底備份恢復數據
innobackupex: Starting to copy InnoDB log files
innobackupex: in '/backups/2014-04-21_11-28-06'
innobackupex: back to original InnoDB log directory '/mydata/data'
innobackupex: Copying '/backups/2014-04-21_11-28-06/ib_logfile0' to '/mydata/data/ib_logfile0'
innobackupex: Copying '/backups/2014-04-21_11-28-06/ib_logfile1' to '/mydata/data/ib_logfile1'
innobackupex: Finished copying back files.
                                                                                                                                                                                                                                                                                                         
140421 14:56:16  innobackupex: completed OK!   #恢復OK


(2)查看下恢復回來的數據

   通過一次徹底和兩次增量備份還原,數據已經恢復到了第二次增量備份時的狀態

[root@shuishui backups]# cd /mydata/data/
[root@shuishui data]# ll     #第二次增量備份前的數據都回來了,只有後來哪一個hhht庫沒有
total 110684
drwxr-xr-x. 2 root root     4096 Apr 21 14:56 bynr
drwxr-xr-x. 2 root root     4096 Apr 21 14:56 hellodb
drwxr-xr-x. 2 root root     4096 Apr 21 14:56 hlbrc
-rw-r--r--. 1 root root 12582912 Apr 21 14:56 ibdata1
-rw-r--r--. 1 root root 50331648 Apr 21 14:56 ib_logfile0
-rw-r--r--. 1 root root 50331648 Apr 21 14:56 ib_logfile1
drwxr-xr-x. 2 root root     4096 Apr 21 14:56 makingware
drwxr-xr-x. 2 root root     4096 Apr 21 14:56 mysql
drwxr-xr-x. 2 root root     4096 Apr 21 14:56 performance_schema
drwxr-xr-x. 2 root root     4096 Apr 21 14:56 test
drwxr-xr-x. 2 root root    61440 Apr 21 14:56 ultrax
#此時數據目錄中的全部文件的屬主屬組都是root,因此要修改爲mysql
[root@shuishui data]# chown -R mysql.mysql *
[root@shuishui data]# ll
total 110684
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 14:56 bynr
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 14:56 hellodb
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 14:56 hlbrc
-rw-r--r--. 1 mysql mysql 12582912 Apr 21 14:56 ibdata1
-rw-r--r--. 1 mysql mysql 50331648 Apr 21 14:56 ib_logfile0
-rw-r--r--. 1 mysql mysql 50331648 Apr 21 14:56 ib_logfile1
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 14:56 makingware
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 14:56 mysql
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 14:56 performance_schema
drwxr-xr-x. 2 mysql mysql     4096 Apr 21 14:56 test
drwxr-xr-x. 2 mysql mysql    61440 Apr 21 14:56 ultrax

(3)使用二進制日誌文件作即時點恢復

   由於咱們在作第二次增量備份後,又修改了數據(建立了數據庫hhht),因此數據只能恢復到第二次增量備份時的狀態,想要恢復之後的數據就只能依靠二進制日誌作即時點恢復了

  ①、 查看xtrabackup_binlog_info中記錄的 mysql服務器當前正在使用的二進制日誌文件及至備份這一刻爲止二進制日誌事件的位置。

[root@shuishui backups]# cat /backups/2014-04-21_11-28-06/xtrabackup_binlog_info
master-bin.000013   105788

  ②、 因爲二進制日誌是無法直接查看的,因此要先把它導出來,而後再看看裏面是否有咱們後來建立的hhht數據庫

[root@shuishui binlogs]# ls
master-bin.000001  master-bin.000004  master-bin.000007  master-bin.000010  master-bin.000013  master-bin.state
master-bin.000002  master-bin.000005  master-bin.000008  master-bin.000011  master-bin.000014
master-bin.000003  master-bin.000006  master-bin.000009  master-bin.000012  master-bin.index
[root@shuishui binlogs]# mysqlbinlog master-bin.000013 > a.sql  #導出二進制日誌

   ③、查看使用二進制日誌導出的a.sql

[root@shuishui binlogs]#vim a.sql

確實有剛纔建立的hhht數據庫,那就是它了。如今把這個二進制日誌文件導出來並附加到數據庫中

wKiom1NVQkOzYRKUAABOPBi9Bwc190.png

   ④、啓動mysql服務,並附加剛纔用二進制日誌文件導出的那個數據庫

[root@shuishui ~]# service mysqld start    #啓動mysql服務
[root@shuishui ~]# mysql
MariaDB [(none)]> set sql_log_bin=0;      #暫時關閉二進制日誌
MariaDB [(none)]> source /mydata/binlogs/a.sql    #導入數據庫
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| bynr               |        #bynr庫回來了
| hellodb            |
| hhht               |        #hhht庫回來了
| hlbrc              |        #hlbrc庫也回來了
| information_schema |
| makingware         |
| mysql              |
| performance_schema |
| test               |
| ultrax             |
+--------------------+
10 rows in set (0.00 sec)
MariaDB [(none)]> set sql_log_bin=1;  #再開啓二進制日誌

   寫到這裏,徹底備份,使用徹底備份恢復;增量備份,使用增量備份進行恢復,還有原理都已經講清楚並演示出來了。好好使用這個工具吧!j_0003.gif

相關文章
相關標籤/搜索