1. 程式人生 > >MySQL資料庫之全量+增量+二進位制日誌的備份與恢復

MySQL資料庫之全量+增量+二進位制日誌的備份與恢復

一、簡介資料的備份與恢復

1、為什麼備份?

  • 災難恢復:人為錯誤、硬體故障(冗餘)、軟體故障(bug)、自然災害、黑客攻擊、誤操作、…;
  • 測試;

2、備份時應該注意些什麼?

  • 能容忍最多丟失多少資料;
  • 恢復資料需要在多長時間內完成;
  • 需要恢復哪些資料;
  • 做恢復演練:測試備份的可用性;增強恢復操作效率;

2、備份的資料集的範圍:

  • 完全備份:整個資料集;
  • 部分備份:資料集的一部分,比如部分表;

3、全量備份、增量備份、差異備份:

  • 完全備份
  • 增量備份:僅備份自上一次完全備份或 增量備份以來變數的那部資料;
  • 差異備份:僅備份自上一次完全備份以來變數的那部資料;

4、根據資料服務是否線上:

  • 熱備:讀寫操作均可進行的狀態下所做的備份;
  • 溫備:可讀但不可寫狀態下進行的備份;
  • 冷備:讀寫操作均不可進行的狀態下所做的備份;

注意:在實際生產環境中,很少有把伺服器機器停下來進行備份,一般是在執行中進行備份資料,而且專門備份的資料相比之下都是較大的資料,所以一般情況使用的是物理熱備。

5、備份策略:

  • 全量+差異 + binlogs
  • 全量+增量 + binlogs

6、備份工具:

  • mysqldump:mysql服務自帶的備份工具,是一種邏輯備份工具,它支援一下方式備份:
    完全、部分備份;
    InnoDB:熱備;
    MyISAM:溫備;

  • cp/tar
    lvm2:快照(請求一個全域性鎖),之後立即釋放鎖,達到幾乎熱備的效果;物理備份;
    注意:不能僅備份資料檔案;要同時備份事務日誌;
    前提:要求資料檔案和事務日誌位於同一個邏輯卷;

  • innobackup[收費] / xtrabackup[免費]:
    由Percona提供,開源工具,支援對InnoDB做熱備,物理備份工具;
    完全備份、部分備份;
    完全備份、增量備份;
    完全備份、差異備份;

二、實現資料庫全量+增量+二進位制日誌備份與恢復

Xtrabackup是MySQL資料庫的備份不可多得的工具之一。提供了全備,增備,資料庫級別,表級別備份等等。
percona-xtrabackup軟體包中中包含了兩個工具,一個是xtrabackup,另一個是innobackupex,innobackupex由per進行封裝,在對innodb表進行備份時會自動呼叫xtraback工具,所以對InnoDB表做備份的實際是xtrabackup這個工具,xtrabackup也只能對innodb表做備份,這是一個專門對innodb開發的熱備工具,而對myisam這樣的其他引擎的表則由innobackupex來負責備份,若是全備份加增量的方案,那每次增量innobackupex工具對非innodb表都是全備份且會請求讀鎖。
xtrabackup對innodb表進行備份時不再只是簡單複製檔案,而是利用在innodb儲存引擎層中的LSN(日誌序列號)的新舊來識別這一資料頁是否需要備份。
xtraback工具對innodb引擎完美支援真正的熱備份,備份好的資料中資料檔案與事務日誌的檔案因innodb cache等因素的存在,所以備份好的資料和事務日誌中的資料往往是不一致的,所以,在做資料恢復時需要把事務日誌中已提交的事務做redo,沒有提交的事務做undo操作,這就是在做資料恢復時要做的準備工作,即prepare。
在以下地址可以下載到xtrabackup:

http://www.percona.com/downloads/XtraBackup/,可以根據自己的需要選擇穩定版本或者最新版本以及作業系統、原始碼包或者rpm包等等。
我下載了最新版的rpm包:percona-xtrabackup-24-2.4.8-1.el7.x86_64.rpm
使用yum安裝可以把依賴的包一起安裝上

[root@node2 ~]#yum install percona-xtrabackup-24-2.4.8-1.el7.x86_64.rpm

每個InnoDB的頁面都會包含一個LSN資訊,每當相關的資料發生改變,相關的頁面的LSN就會自動增長。這正是InnoDB表可以進行增量備份的基礎,即innobackupex通過備份上次完全備份之後發生改變的頁面來實現。
實驗環境:兩臺安裝centos7系統的主機,A主機上安裝Mariadb資料庫,並且已經初始化,B主機上安裝了Mariadb資料庫,沒有初始化。並且A和B都安裝了percona-xtrabackup-24-2.4.8-1.el7.x86_64.rpm
需要注意的是,增量備份僅能應用於InnoDB表,對於MyISAM表而言,執行增量備份時其實進行的是完全備份。
在A主機上:
建立一個數據庫test,並且在資料下建立一個students表,裡面添加了若干資料資料。

表結構 
MariaDB [(none)]> DESC test.students;
+--------+---------------------+------+-----+---------+----------------+
| Field  | Type                | Null | Key | Default | Extra          |
+--------+---------------------+------+-----+---------+----------------+
| id     | int(10) unsigned    | NO   | PRI | NULL    | auto_increment |
| name   | char(30)            | NO   |     | NULL    |                |
| age    | tinyint(3) unsigned | YES  | MUL | NULL    |                |
| gender | enum('F','M')       | YES  |     | NULL    |                |
| major  | varchar(100)        | YES  |     | NULL    |                |
+--------+---------------------+------+-----+---------+----------------+
5 rows in set (0.05 sec)
表中的資料
MariaDB [(none)]> select * from test.students;
.............................
| 3089 | stu89    |   95 | M      | NULL   |
| 3090 | stu90    |   87 | F      | NULL   |
+------+----------+------+--------+--------+

備份
全量備份

mkdir /mysdate/backups -pv    #建立備份檔案存放的目錄
[[email protected] ~]#innobackupex --user=root --password=magedu --host=localhost /mydate/backups/    #全量備份
.....................
.....................
171114 09:57:11 completed OK!
[[email protected] ~]#cd /mydate/backups/
[[email protected] /mydate/backups]#ls
2017-11-11_10-02-09          #以當前時間命令的備份檔案 
[[email protected] /mydate/backups]#ll 2017-11-11_10-02-09/   
total 18460
-rw-r-----. 1 root root      417 Nov 11 10:02 backup-my.cnf    配置資訊 
-rw-r-----. 1 root root 18874368 Nov 11 10:02 ibdata1
drwxr-x---. 2 root root     4096 Nov 11 10:02 mysql        
drwxr-x---. 2 root root     4096 Nov 11 10:02 performance_schema
drwxr-x---. 2 root root     4096 Nov 11 10:02 test
-rw-r-----. 1 root root      113 Nov 11 10:02 xtrabackup_checkpoints  二進位制檔案的資訊,備份的那一刻,處在什麼位置
-rw-r-----. 1 root root      449 Nov 11 10:02 xtrabackup_info      備份的資訊,版本,時間
-rw-r-----. 1 root root     2560 Nov 11 10:02 xtrabackup_logfile

第一次修改資料

MariaDB [(none)]> INSERT INTO test.students VALUE (3100,'xiaoming',18,'M','shuxue');
MariaDB [(none)]> select * from test.students;
.............................
| 3089 | stu89    |   95 | M      | NULL   |
| 3090 | stu90    |   87 | F      | NULL   |
| 3100 | xiaoming |   18 | M      | shuxue |
+------+----------+------+--------+--------+

修改資料後,第一次增量備份

[[email protected] ~]#innobackupex --user=root --password=magedu --host=localhost --incremental /mydate/backups/ --incremental-basedir=/mydate/backups/2017-11-14_09-51-50
[[email protected] /mydate/backups/2017-11-14_09-51-50]#cat  xtrabackup_checkpoints    #檢視備份檔案
backup_type = full-backuped     # 全量備份 
from_lsn = 0                #從0位置開始
to_lsn = 2622741            #到2622741
last_lsn = 2622741
compact = 0
recover_binlog_info = 0

第二次修改資料

MariaDB [(none)]> DELETE FROM test.students WHERE id='3090';
Query OK, 1 row affected (0.05 sec)
MariaDB [(none)]> select * from test.students;
.............................
| 3089 | stu89    |   95 | M      | NULL   |
| 3100 | xiaoming |   18 | M      | shuxue |
+------+----------+------+--------+--------+

第二次修改資料後增量備份

[root@node2 ~]#innobackupex --user=root --password=magedu --host=localhost --incremental /mydate/backups/ --incremental-basedir=/mydate/backups/2017-11-14_09-57-07
[root@node2 /mydate/backups]#ll
total 12
drwxr-x---. 5 root root 4096 Nov 14 09:51 2017-11-14_09-51-50      #全量備份檔案
drwxr-x---. 5 root root 4096 Nov 14 09:57 2017-11-14_09-57-07      #第一次增量備份檔案
drwxr-x---. 5 root root 4096 Nov 14 10:08 2017-11-14_10-08-11      #第二次增量備份檔案
[root@node2 /mydate/backups/2017-11-14_09-57-07]#cat xtrabackup_checkpoints 
backup_type = incremental   #增量備份 
from_lsn = 2622741          #從2622741
to_lsn = 2623193            #至2623193
last_lsn = 2623193
compact = 0
recover_binlog_info = 0

第三次修改

MariaDB [(none)]> UPDATE test.students SET major='yingyu' WHERE id='3100';
MariaDB [(none)]> select * from test.students;
......................
| 3089 | stu89    |   95 | M      | NULL   |
| 3100 | xiaoming |   18 | M      | yingyu |
+------+----------+------+--------+--------+

修改之後,這時候,伺服器宕機,資料庫崩潰,需要我們恢復資料,但是二進位制日誌還在。
檢視最後一次增量備份完成的位置,以確定後面的操作二進位制日誌開始紀錄的位置,並二進位制日誌還原資料增量備份之後的資料

[root@node2 /mydate/backups/2017-11-14_10-08-11]#cat xtrabackup_binlog_info 
ON.000001   651

備份增量備份之後的二進位制日誌檔案

[root@node2 ~]#mysqlbinlog -j 651 /var/lib/mysql/ON.000001 > /root/mysql.sql

把A機器上的備份的檔案,以及二進位制日誌檔案拷貝到B機器上,準備做恢復操作。
注意:備份的資料不應該和原資料存放在一起,如果遭受遭難,那麼備份的資料和原資料一起被損壞,備份就失去意義了。
恢復
準備增量備份與整理完全備份有著一些不同,尤其要注意的是:
(1)需要在每個備份(包括完全和各個增量備份)上,將已經提交的事務進行“重放”。“重放之後”,所有的備份資料將合併到完全備份上。
(2)基於所有的備份將未提交的事務進行“回滾”。全量備份檔案中完成和未完成的,執行提交和回滾操作。
全量備份檔案中完成和未完成的,執行提交和回滾操作

[root@localhost ~]#innobackupex --apply-log --redo-only /root/2017-11-14_09-51-50  

第一次增量備份檔案中完成和未完成的,執行提交和回滾操作

[[email protected] ~]#innobackupex --apply-log --redo-only /root/2017-11-14_09-51-50 --incremental-dir /root/2017-11-14_09-57-07

第二次增量備份檔案中完成和未完成的,執行提交和回滾操作

[[email protected] ~]#innobackupex --apply-log --redo-only /root/2017-11-14_09-51-50 --incremental-dir /root/2017-11-14_10-08-11

全部在滾回提交一次

[root@localhost ~]#innobackupex --apply-log /root/2017-11-14_09-51-50

同時可以注意到,備份開始的位置是全量備份最初的位置,結束的位置,是第二次增量備份結束的位置。

[[email protected] ~/2017-11-14_09-51-50]#cat xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0    #開始
to_lsn = 2623711   #結束
last_lsn = 2623711
compact = 0
recover_binlog_info = 0

恢復全量+第一次增量+第二次增量備份資料

[root@localhost ~]#innobackupex --copy-back 2017-11-14_09-51-50    #恢復資料

如下,資料庫中已經有對應的資料

[[email protected] /var/lib/mysql]#ll
total 40980
-rw-r-----. 1 root root 18874368 Nov 14 11:02 ibdata1
-rw-r-----. 1 root root  5242880 Nov 14 11:02 ib_logfile0
-rw-r-----. 1 root root  5242880 Nov 14 11:02 ib_logfile1
-rw-r-----. 1 root root 12582912 Nov 14 11:02 ibtmp1
drwxr-x---. 2 root root     4096 Nov 14 11:02 mysql
drwxr-x---. 2 root root     4096 Nov 14 11:02 performance_schema
drwxr-x---. 2 root root     4096 Nov 14 11:02 test
-rw-r-----. 1 root root       16 Nov 14 11:02 xtrabackup_binlog_pos_innodb
-rw-r-----. 1 root root      564 Nov 14 11:02 xtrabackup_info

把備份資料檔案的所屬主和所屬組修改為mysql

[[email protected] /var/lib/mysql]#chown -R mysql.mysql ./ 
[[email protected] /var/lib/mysql]#ll
total 40980
-rw-r-----. 1 mysql mysql 18874368 Nov 14 11:02 ibdata1
-rw-r-----. 1 mysql mysql  5242880 Nov 14 11:02 ib_logfile0
-rw-r-----. 1 mysql mysql  5242880 Nov 14 11:02 ib_logfile1
-rw-r-----. 1 mysql mysql 12582912 Nov 14 11:02 ibtmp1
drwxr-x---. 2 mysql mysql     4096 Nov 14 11:02 mysql
drwxr-x---. 2 mysql mysql     4096 Nov 14 11:02 performance_schema
drwxr-x---. 2 mysql mysql     4096 Nov 14 11:02 test
-rw-r-----. 1 mysql mysql       16 Nov 14 11:02 xtrabackup_binlog_pos_innodb
-rw-r-----. 1 mysql mysql      564 Nov 14 11:02 xtrabackup_info

登陸資料庫,需要注意的是,登陸的使用者名稱,密碼都是原資料的使用者名稱和密碼

MariaDB [(none)]> select * from test.students;
| 3088 | stu88    |   38 | M      | NULL   |
| 3089 | stu89    |   95 | M      | NULL   |
| 3100 | xiaoming |   18 | M      | shuxue |
+------+----------+------+--------+--------+
1089 rows in set (0.07 sec)

細心的朋友可以看到,我們並沒有完全恢復資料,還有增量備份之後的資料還沒恢復。

MariaDB [(none)]> SET @@session.sql_log_bin=OFF;
MariaDB [(none)]> \. /tmp/mysql.sql
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> SET @@session.sql_log_bin=ON;
Query OK, 0 rows affected (0.00 sec)

恢復完成,和宕機之前資料做對比,完全一樣,恢復成功
MariaDB [(none)]> select * from test.students;
| 3088 | stu88 | 38 | M | NULL |
| 3089 | stu89 | 95 | M | NULL |
| 3100 | xiaoming | 18 | M | yingyu |
+——+———-+——+——–+——–+
1089 rows in set (0.01 sec)

恢復完成後,不要著急上線,趕緊做一次全量備份,生成新的序列。

相關推薦

MySQL資料庫+增量+二進位制日誌備份恢復

一、簡介資料的備份與恢復 1、為什麼備份? 災難恢復:人為錯誤、硬體故障(冗餘)、軟體故障(bug)、自然災害、黑客攻擊、誤操作、…; 測試; 2、備份時應該注意些什麼? 能容忍最多丟失多少資料; 恢復資料需要在多長時間內完成; 需要恢復哪些資料;

Mysql備份系列(3)--innobackupex備份mysql大資料(+增量)操作記錄

    在日常的linux運維工作中,大資料量備份與還原,始終是個難點。關於mysql的備份和恢復,比較傳統的是用mysqldump工具,今天這裡推薦另一個備份工具innobackupex。innobackupex和mysqldump都可以對mysql進行熱備份的,mys

MySQL自動化(+增量備份指令碼

文章轉自:http://www.it-hack.cn/forum.php?mod=viewthread&tid=220&extra=page%3D1一、MySQL的日常備份方案:全備+增量備份:1、週日凌晨三點進行全備;2、週一到週日增量備份。不是往常的週日全備份,週一到週六增量備份,這樣如果

mysql 開發進階篇系列 42 邏輯備份恢復

一.概述          在作何資料庫裡,備份與恢復都是非常重要的。好的備份方法和備份策略將會使得資料庫中的資料更加高效和安全。對於DBA來說,進行備份或恢復操作時要考慮的因素大概有如下: (1) 確定要備份的表的儲存引擎是事務型(innodb)還是非事務型。兩種不同的儲存引擎備份方式在處理資料一致性方面

mysql 開發進階篇系列 43 邏輯備份恢復(基於時間和位置的不完全恢復)

一. 概述          在上篇講到了邏輯備份,使用mysqldump工具來備份一個庫,並使用完全恢復還原了資料庫。在結尾也講到了誤操作是不能用完全恢復的。解決辦法是:我們需要恢復到誤操作之前的狀態,然後跳過誤操作語句。再恢復後面執行的語句,完成我們的恢復,這種恢復叫“不完全恢復”。在mysql 中,不完

mysql 開發進階篇系列 44 物理備份恢復( 熱備份xtrabackup 工具介紹)

一.概述   物理備份和恢復又分為冷備份和熱備份。與邏輯備份相比,它最大優點是備份和恢復的速度更快。因為物理備份的原理都是基於檔案的cp。   1.1 冷備份    冷備份就是停掉資料庫服務。這種物理備份一般很少使用,因為很多應用是不允許長時間停機的。恢復操作大概是:首先停掉mysql服務, 在作業系統級別恢

【每日一學】數據倉庫表、增量表、拉鏈表、流水表

水表 打開 tails 開始 當我 net 最大的 閱讀 增量 每日一悟 數據倉庫之全量表、增量表、拉鏈表、流水表 背景 從使用MySQL階段,到前陣子跳槽到新公司開始使用hive,面對的表變多,數據量也完全超過之前。基本是隨便核查個問題都已經不是Excel能承擔得起的了

lvm-snapshot備份mysql資料(+增量

lvm-snapshot:基於LVM快照的備份 1.關於快照: 1)事務日誌跟資料檔案必須在同一個捲上; 2)剛剛創立的快照卷,裡面沒有任何資料,所有資料均來源於原卷 3)一旦原卷資料發生修改,修改的資料將複製到快照卷中,此時訪問資料一部分來自於快照卷,一部分來自於原卷 4)當快照使用過程中,如果修

Elasticsearch使用Logstash-input-jdbc同步mysql資料(增量

作者:camelcanoe 來源:CSDN 原文:https://blog.csdn.net/camelcanoe/article/details/79759376 版權宣告:本文為博主原創文章,轉載請附上博文連結! 專案中用到elasticsearch,初始化資料時時寫的程式從資

大資料量同步方案同步改為增量同步解決方案

背景描述:   在一些大資料運用場景中,由於上游資料每天都在變化著,在需要用這些資料的下游系統需要每天重新整理這些變化的資料,當資料量小時候,簡單粗暴的方式就是每次全量更新資料,但隨著業務的增長,資料量成幾何方式增長時(達到億級別甚至更多),每次的更新工作將是

Elasticsearch使用Logstash-input-jdbc同步mysql資料(增量)(windows)

專案中用到elasticsearch,初始化資料時時寫的程式從資料庫裡面查詢出來,然後多執行緒往elasticsearch裡面寫入的。今天試了一下Logstash-input-jdbc外掛,發現高效又方便,而且可以設定定時任務。1、安裝外掛在logstash的bin目錄下執行

阿里雲RDS(mysql)異機增量恢復

使用阿里雲的RDS服務(也就是MySQL資料庫)時,有時需要將其資料取出後拿到別的機器上使用,這就需要進行RDS的異機恢復。 說明:本文恢復使用的機器環境為CentOS 6.5 x64。 1. 獲取備份下載地址 RDS控制檯 -> 備份恢復 -> 資

Mysql備份+增量+恢復)方案操作記錄

1、開啟mysql的binlog日誌&檢視$備份 2、shell指令碼 mysqldump 變數說明 --all-databases針對所有資料庫進行備份  --databases databasename 針對單個數據庫進行備份 --flush-logs為結束當前

mysql 備份恢復(增量)

全量備份使用自帶的mysqldump命令備份命令mysqldump -u[username] -p[password]  [database] [table] > backup.sql恢復命令mysql -u[username] -p[password] [database] &l

Xtrabackup 備份資料庫備份增量備份

Xtrabackup Xtrabackup是由percona開源的免費資料庫熱備份軟體,它能對InnoDB資料庫和XtraDB儲存引擎的資料庫非阻塞地備份(對於MyISAM的備份同樣需要加表鎖);mysqldump備份方式是採用的邏輯備份,其最大的缺陷是備份和恢復速度較

阿里巴巴去Oracle資料遷移同步工具(+增量,目標支援MySQL/DRDS)

摘要: 阿里資料庫遷移專案yugong開源啦!yugong解決了單機Oracle無法滿足的擴充套件性問題,當時也掀起一股去IOE專案的浪潮,愚公這專案因此而誕生,其要解決的目標就是幫助使用者完成從Oracle資料遷移到MySQL上,完成去IOE的第一步。DBA的小夥伴們趕快來圍觀! 專案簡介 yugong(

Oracle Database 12c RMAN+增量備份+歸檔日誌恢復詳解

Oracle可以非常方便的把資料庫恢復到具體某個時間的狀態,而且還支援全備和多級增備,備份無需停止應用服務。比起DB2需要手動逐級恢復增量備份和歸檔日誌,RMAN是非常簡單好用的資料庫商業解決方案。下面是我的環境:作業系統:CentOS 6.7Oracle版本:Oracle

MySQL資料以增量方式,同步到ES搜尋引擎

一、配置詳解 場景描述:MySQL資料表以全量和增量的方式向ElasticSearch搜尋引擎同步。 1、下載內容 elasticsearch 版本 6.3.2 logstash 版本 6.3.2 mysql-connector-java-5.1.13.jar 2、核心配置 路徑:/usr/local

XtraBackup備份恢復MySQL數據

備份 mysql xtrabackup 防偽碼:沒有相當程度的孤獨是不可能有內心的平和。1、概述Percona XtraBackup(簡稱PXB)是 Percona 公司開發的一個用於 MySQL 數據庫物理熱備的備份工具,支持 MySQl(Oracle)、Percona Server 和 Mar

二、mysql資料庫基本操作和儲存引擎

一、知識儲備 資料庫伺服器:一臺計算機(對記憶體要求比較高) 資料庫管理系統:如mysql,是一個軟體 資料庫:oldboy_stu,相當於資料夾 表:student,scholl,class_list,相當於一個具體的檔案 記錄:1 susan &nb