Mysql數據庫按時間點恢復實戰

時間 2021-06-29

標籤 mysql sql 數據庫網絡 app 工具阿里雲 spa 線程日誌欄目 MySQL 简体版

原文原文鏈接

簡介：Mysql數據庫按時間點恢復實戰

對於任何一家企業來說，數據都是最寶貴的財富。mysql

如何保護數據完整性，數據不受損壞，在發生故障時，如何保住數據，在發生誤操做，黑客入侵，數據篡改等場景時，如何基於咱們的備份來進行數據恢復，是每一個技術人員須要關注的關鍵點。sql

阿里雲致力於服務客戶，爲客戶數據庫提供連續數據保護、低成本的備份服務。它能夠爲多種環境的數據提供強有力的保護，以及強力恢復。在發生數據丟失、數據損壞的極端狀況下，RDS管控平臺具備一鍵還原的功能，基於客戶設置的須要恢復的時間點，進行數據全方位恢復。數據庫

1. 按時間點恢復的技術實現

若是客戶在某時間節點因爲誤操做，致使數據丟失，RDS管控服務是如何進行恢復的呢？網絡

按時間點恢復的總體思路以下：一次完整的數據恢復是由物理備份+binlog恢復+binlog裁剪構成的。app

圖1工具

首先獲取到可用的備份集，將備份集應用到目標實例上，而後再目標實例重放須要恢復的binlog文件，最後經過binlog裁剪的形式應用sql文件，實現總體的恢復。阿里雲

2. 按時間點恢復的管控流程

1. 建立用於恢復的目的實例

當咱們須要總體恢復源數據庫數據時，咱們首先須要建立一個與源實例同規格、同網絡環境的目標實例。spa

爲何要這樣作?線程

由於備份恢復屬於高危操做，若是直接還原到源實例，一旦出現備份集不可用、binlog缺失等等問題，那麼不只丟失數據沒法找回，甚至原數據都沒法無缺保住，因此強烈建議使用新實例來進行恢復！日誌

2. 明確備份恢復時間點

當客戶在執行了一系列數據庫操做以後，如誤刪除、誤修改等，操做以後無感知，等到業務受損、故障發生時，如何定位到當時操做的準確時間點用於數據恢復呢？

方式1：能夠經過日誌審計功能找到對應的誤操做時間點。

方式2：能夠將binlog解析成文本，查詢對應的誤操做時間點。

3. 經過備份歷史獲取可用的備份集

通常狀況下，基於業務的重要程度，客戶在雲上會規劃好本身的數據庫備份週期，RDS管控會基於用戶選擇的恢復時間點自動尋找可用的物理備份集。

可見備份對於數據庫的高可用和災難恢復是重中之重的！

4. 獲取備份集對應的binlog點位

專有云的備份通常都基於xtrabackup工具進行備份。xtrabackup具備熱備份、恢復快等特色，同時會將備份結束時應用binlog的文件和點位寫入相應文件中。RDS管控會將該binlogfile和binlogpos等信息寫入數據庫，當須要備份恢復時，會直接獲取該點位進行恢復。

以下圖所示：

圖2

5. 將備份集還原至目的實例

1-4步驟爲準備工做，下面開始正式的恢復數據。恢復數據的第一步是將獲取的可用的全量物理備份集下載至目的實例上，並使用xtrabackup工具進行還原。

//首先要中止目的實例上的mysql進程

systemctl stop mysql

//而後合併數據,假設備份解壓在/root/backup/目錄下,能夠指定須要恢復的實例端口，需加--defaults-file參數指定，默認3306。

innobackupex --apply-log /root/backup/

//刪除原目錄文件

rm -rf /data/mysql

//還原數據集,還原數據到哪一個目錄是基於配置文件my.cnf的datadir決定的。該字段必定要檢查是否準確

innobackupex --copy-back /root/backup/

//目錄賦權

chown -R mysql:mysql /data/mysql

6. 驗證還原是否成功

管控服務須要驗證還原是否成功，再決定是否須要向下操做，驗證步驟也很簡單粗暴，直接檢查備份恢復日誌中是否有ERROR,而且最後一行是否爲completed OK!

以下圖，爲一次成功的備份恢復。

圖3

7. 獲取用於恢復的binlog日誌

此步驟相當重要，關乎恢復是否成功，數據是否完整。

那麼RDS管控服務如何獲取正確的binlog來進行恢復呢？咱們來看下圖。

圖4

例如當前咱們的備份中總共有8個binlog備份(000-008)，首先經過物理備份記錄的binlog的filename和pos來獲取第一個binlog，如上圖中的binlog004；而後經過客戶設置的須要恢復的時間點的timestamp，來找到對應的最後一個binlog，如上圖中的binlog007；最後將binlog004,binlog005,binlog006,binlog007這四個binlog備份下載到目的實例上進行恢復。

若是獲取了錯誤的binlog日誌用於恢復，好比誤將binlog003/binlog005設置成了第一個binlog，那麼binlog003/binlog005上執行的dml語句會在新實例上從新執行一次，恢復的數據就會增多或缺失；好比誤將binlog0006或者binlog0008設置成了最後一個binlog，那麼恢復的數據會缺失，且沒法達到預期效果。

8. 重放relaylog

將下載的binlog複製到新實例的logdir中，並將除最後一個binlog(覆蓋恢復時間點的binlog)以外的binlog重命名爲relaylog，而後使用新實例重放這些relaylog。

//將binlog重命名,relaylog文件名可在mysql實例中執行show variables like '%relay%'查看.

rename mysql-bin MySQL2-relay-bin mysql-bin*

//將relay信息初始化到index文件中

ls ./MySQL2-relay-bin.0000*>MySQL2-relay-bin.index

//將這些文件複製到data文件中

cp MySQL2-relay-bin.*/data/mysql/

//文件賦權

chown -R mysql:mysql /data/mysql

//啓動mysql實例

systemctl start mysql

//change master to一個不存在的實例，模擬此實例爲一個備庫,指定一個空的主庫，建立SQL線程,而後根據備份記錄的binlogfile和binlogpos來設置。並啓動slave的sql_thread

CHANGE MASTER TO MASTER_HOST='1.1.1.1',RELAY_LOG_FILE='MySQL2-relay-bin.000011',RELAY_LOG_POS=160338;

START SLAVE SQL_THREAD;

show slave status\G

9. 驗證relaylog重放成功

經過show slave status\G，來進行驗證，此步驟通常恢復較慢，取決於數據庫binlog個數及binlog大小。

驗證1：查看relay\_log\_file字段的值是否爲咱們在MySQL2-relay-bin.index文件中維護的最大的值，若是是的話，則證實全部的bilog已重放成功；

驗證2：查看Slave\_SQL\_Running字段是否爲YES。

以下圖所示：

圖5

10. 經過mysqlbinlog功能裁剪恢復時間點上的binlog，並生成sql文件

至此，1-9步驟已經恢復了絕大部分數據了，剩餘了一個覆蓋咱們恢復時間點的binlog未進行恢復。

那麼咱們如何來進行操做呢？

以下圖所示：

圖6

根據客戶的時間點(如須要恢復至15:00的數據)，RDS管控須要將覆蓋咱們恢復時間點的binlog根據恢復時間進行裁剪，也就是隻應用12:00-15:00的數據，15:00至18:00的數據屬於誤操做時間，不該該拿來應用。

//使用mysqlbinlog工具的裁剪功能對該binlog進行裁剪

mysqlbinlog --start-position=4--stop-datetime='2021-04-23 15:00:00'-R -h127.0.0.1-uroot -pxxxx -P3306 mysql-bin.007>/tmp/mysql-bin.007.sql

11. 目的實例經過sql文件，執行須要恢復的數據

在目的實例上執行該sql文件。

//賦權

chown mysql:mysql /tmp/mysql-bin.007.sql

//恢復數據

mysql -uroot -pxxxx -h127.0.0.1-P3306 -f --max_allowed_packet=1073741824</root/mysql-bin.007.sql

12. 驗證數據

至此，總體的備份恢復就已經完成了，下面就須要客戶來進行驗證數據，已經將目的實例的數據恢復到源實例中。

咱們是阿里雲智能全球技術服務-SRE團隊，咱們致力成爲一個以技術爲基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提高業務穩定性。咱們指望可以分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。