簡介：Mysql數據庫按時間點恢復實戰(zhàn)

對于任何一家企業(yè)來講，數據都是最寶貴的財富。

如何保護數據完整性，數據不受損壞，在發(fā)生故障時，如何保住數據，在發(fā)生誤操作，黑客入侵，數據篡改等場景時，如何基于我們的備份來進行數據恢復，是每個技術人員需要關注的關鍵點。

阿里云致力于服務客戶，為客戶數據庫提供連續(xù)數據保護、低成本的備份服務。它可以為多種環(huán)境的數據提供強有力的保護，以及強力恢復。在發(fā)生數據丟失、數據損壞的極端情況下，RDS管控平臺具有一鍵還原的功能，基于客戶設置的需要恢復的時間點，進行數據全方位恢復。

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

如果客戶在某時間節(jié)點由于誤操作，導致數據丟失，RDS管控服務是如何進行恢復的呢？

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

圖1

首先獲取到可用的備份集，將備份集應用到目標實例上，然后再目標實例重放需要恢復的binlog文件，最后通過binlog裁剪的形式應用sql文件，實現整體的恢復。

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

1. 創(chuàng)建用于恢復的目的實例

當我們需要整體恢復源數據庫數據時，我們首先需要創(chuàng)建一個與源實例同規(guī)格、同網絡環(huán)境的目標實例。

為什么要這樣做?

因為備份恢復屬于高危操作，如果直接還原到源實例，一旦出現備份集不可用、binlog缺失等等問題，那么不僅丟失數據無法找回，甚至原數據都無法完好保住，所以強烈建議使用新實例來進行恢復！

2. 明確備份恢復時間點

當客戶在執(zhí)行了一系列數據庫操作之后，如誤刪除、誤修改等，操作之后無感知，等到業(yè)務受損、故障發(fā)生時，如何定位到當時操作的準確時間點用于數據恢復呢？

方式1：可以通過日志審計功能找到對應的誤操作時間點。

方式2：可以將binlog解析成文本，查詢對應的誤操作時間點。

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

一般情況下，基于業(yè)務的重要程度，客戶在云上會規(guī)劃好自己的數據庫備份周期，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上執(zhí)行的dml語句會在新實例上重新執(zhí)行一次，恢復的數據就會增多或缺失；比如誤將binlog0006或者binlog0008設置成了最后一個binlog，那么恢復的數據會缺失，且無法達到預期效果。

8. 重放relaylog

將下載的binlog復制到新實例的logdir中，并將除最后一個binlog(覆蓋恢復時間點的binlog)之外的binlog重命名為relaylog，然后使用新實例重放這些relaylog。

​//​​將binlog重命名,relaylog文件名可在mysql實例中執(zhí)行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​​一個不存在的實例，模擬此實例為一個備庫,指定一個空的主庫，創(chuàng)建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文件，執(zhí)行需要恢復的數據

在目的實例上執(zhí)行該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團隊，我們致力成為一個以技術為基礎、面向服務、保障業(yè)務系統高可用的工程師團隊；提供專業(yè)、體系化的SRE服務，幫助廣大客戶更好地使用云、基于云構建更加穩(wěn)定可靠的業(yè)務系統，提升業(yè)務穩(wěn)定性。我們期望能夠分享更多幫助企業(yè)客戶上云、用好云，讓客戶云上業(yè)務運行更加穩(wěn)定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里云SRE技術學院釘釘圈子，和更多云上人交流關于云平臺的那些事。

原文鏈接：https://developer.aliyun.com/article/784887?

版權聲明：本文內容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協議》和《阿里云開發(fā)者社區(qū)知識產權保護指引》。如果您發(fā)現本社區(qū)中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區(qū)將立刻刪除涉嫌侵權內容。

到此這篇關于Mysql數據庫按時間點恢復實戰(zhàn)的文章就介紹到這了,更多相關Mysql恢復數據庫內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！