主頁 > 知識庫 > Mysql數(shù)據(jù)庫按時間點恢復(fù)實戰(zhàn)記錄

Mysql數(shù)據(jù)庫按時間點恢復(fù)實戰(zhàn)記錄

熱門標簽:北京金倫外呼系統(tǒng) 催天下外呼系統(tǒng) 武漢電銷機器人電話 大豐地圖標注app 400電話變更申請 html地圖標注并導(dǎo)航 南太平洋地圖標注 400電話辦理服務(wù)價格最實惠 呂梁外呼系統(tǒng)

簡介:Mysql數(shù)據(jù)庫按時間點恢復(fù)實戰(zhàn)

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

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

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

​​1. 按時間點恢復(fù)的技術(shù)實現(xiàn)​

如果客戶在某時間節(jié)點由于誤操作,導(dǎo)致數(shù)據(jù)丟失,RDS管控服務(wù)是如何進行恢復(fù)的呢?

按時間點恢復(fù)的整體思路如下:一次完整的數(shù)據(jù)恢復(fù)是由物理備份+binlog恢復(fù)+binlog裁剪構(gòu)成的。

圖1

首先獲取到可用的備份集,將備份集應(yīng)用到目標實例上,然后再目標實例重放需要恢復(fù)的binlog文件,最后通過binlog裁剪的形式應(yīng)用sql文件,實現(xiàn)整體的恢復(fù)。

2. 按時間點恢復(fù)的管控流程

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

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

為什么要這樣做?

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

2. 明確備份恢復(fù)時間點

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

方式1:可以通過日志審計功能找到對應(yīng)的誤操作時間點。

方式2:可以將binlog解析成文本,查詢對應(yīng)的誤操作時間點。

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

一般情況下,基于業(yè)務(wù)的重要程度,客戶在云上會規(guī)劃好自己的數(shù)據(jù)庫備份周期,RDS管控會基于用戶選擇的恢復(fù)時間點自動尋找可用的物理備份集。

可見備份對于數(shù)據(jù)庫的高可用和災(zāi)難恢復(fù)是重中之重的!

4. 獲取備份集對應(yīng)的binlog點位

專有云的備份一般都基于xtrabackup工具進行備份。xtrabackup具有熱備份、恢復(fù)快等特點,同時會將備份結(jié)束時應(yīng)用binlog的文件和點位寫入相應(yīng)文件中。RDS管控會將該binlogfilebinlogpos等信息寫入數(shù)據(jù)庫,當需要備份恢復(fù)時,會直接獲取該點位進行恢復(fù)。

如下圖所示:

圖2

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

1-4步驟為準備工作,下面開始正式的恢復(fù)數(shù)據(jù)?;謴?fù)數(shù)據(jù)的第一步是將獲取的可用的全量物理備份集下載至目的實例上,并使用xtrabackup工具進行還原。

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

​systemctl stop mysql​

​//​​然后合并數(shù)據(jù),假設(shè)備份解壓在/root/backup/目錄下,可以指定需要恢復(fù)的實例端口,需加--defaults-file參數(shù)指定,默認3306。​

​innobackupex ​​--​​apply​​-​​log ​​/​​root​​/​​backup​​/​

​//​​刪除原目錄文件​

​rm ​​-​​rf ​​/​​data​​/​​mysql​

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

​innobackupex ​​--​​copy​​-​​back ​​/​​root​​/​​backup​​/​

​//​​目錄賦權(quán)​

​chown ​​-​​R mysql:mysql ​​/​​data​​/​​mysql

6. 驗證還原是否成功

管控服務(wù)需要驗證還原是否成功,再決定是否需要向下操作,驗證步驟也很簡單粗暴,直接檢查備份恢復(fù)日志中是否有ERROR,并且最后一行是否為completed OK!

如下圖,為一次成功的備份恢復(fù)。

圖3

7. 獲取用于恢復(fù)的binlog日志

此步驟至關(guān)重要,關(guān)乎恢復(fù)是否成功,數(shù)據(jù)是否完整。

那么RDS管控服務(wù)如何獲取正確的binlog來進行恢復(fù)呢?我們來看下圖。

圖4

例如當前我們的備份中總共有8個binlog備份(000-008),首先通過物理備份記錄的binlog的filename和pos來獲取第一個binlog,如上圖中的binlog004;然后通過客戶設(shè)置的需要恢復(fù)的時間點的timestamp,來找到對應(yīng)的最后一個binlog,如上圖中的binlog007;最后將binlog004,binlog005,binlog006,binlog007這四個binlog備份下載到目的實例上進行恢復(fù)。

如果獲取了錯誤的binlog日志用于恢復(fù),比如誤將binlog003/binlog005設(shè)置成了第一個binlog,那么binlog003/binlog005上執(zhí)行的dml語句會在新實例上重新執(zhí)行一次,恢復(fù)的數(shù)據(jù)就會增多或缺失;比如誤將binlog0006或者binlog0008設(shè)置成了最后一個binlog,那么恢復(fù)的數(shù)據(jù)會缺失,且無法達到預(yù)期效果。

8. 重放relaylog

將下載的binlog復(fù)制到新實例的logdir中,并將除最后一個binlog(覆蓋恢復(fù)時間點的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​

​//​​將這些文件復(fù)制到data文件中​

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

​//​​文件賦權(quán)​

​chown ​​-​​R mysql:mysql ​​/​​data​​/​​mysql​

​//​​啟動mysql實例​

​systemctl start mysql​

​//change master to​​一個不存在的實例,模擬此實例為一個備庫,指定一個空的主庫,創(chuàng)建SQL線程,然后根據(jù)備份記錄的binlogfile和binlogpos來設(shè)置。并啟動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,來進行驗證,此步驟一般恢復(fù)較慢,取決于數(shù)據(jù)庫binlog個數(shù)及binlog大小。

驗證1:查看relay_log_file字段的值是否為我們在MySQL2-relay-bin.index文件中維護的最大的值,如果是的話,則證明所有的bilog已重放成功;

驗證2:查看Slave_SQL_Running字段是否為YES。

如下圖所示:

圖5

10. 通過mysqlbinlog功能裁剪恢復(fù)時間點上的binlog,并生成sql文件

至此,1-9步驟已經(jīng)恢復(fù)了絕大部分數(shù)據(jù)了,剩余了一個覆蓋我們恢復(fù)時間點的binlog未進行恢復(fù)。

那么我們?nèi)绾蝸磉M行操作呢?

如下圖所示:

圖6

根據(jù)客戶的時間點(如需要恢復(fù)至15:00的數(shù)據(jù)),RDS管控需要將覆蓋我們恢復(fù)時間點的binlog根據(jù)恢復(fù)時間進行裁剪,也就是只應(yīng)用12:00-15:00的數(shù)據(jù),15:00至18:00的數(shù)據(jù)屬于誤操作時間,不應(yīng)該拿來應(yīng)用。

//​​使用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í)行需要恢復(fù)的數(shù)據(jù)

在目的實例上執(zhí)行該sql文件。

//​​賦權(quán)​

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

​//​​恢復(fù)數(shù)據(jù)​
​mysql ​​-​​uroot ​​-​​pxxxx ​​-​​h127.​​0.0​​.​​1​​​​-​​P3306 ​​-​​f ​​--​​max_allowed_packet​​=​​1073741824​​​​​​​​/​​root​​/​​mysql​​-​​bin.​​007.​​sql

12. 驗證數(shù)據(jù)

至此,整體的備份恢復(fù)就已經(jīng)完成了,下面就需要客戶來進行驗證數(shù)據(jù),已經(jīng)將目的實例的數(shù)據(jù)恢復(fù)到源實例中。

我們是阿里云智能全球技術(shù)服務(wù)-SRE團隊,我們致力成為一個以技術(shù)為基礎(chǔ)、面向服務(wù)、保障業(yè)務(wù)系統(tǒng)高可用的工程師團隊;提供專業(yè)、體系化的SRE服務(wù),幫助廣大客戶更好地使用云、基于云構(gòu)建更加穩(wěn)定可靠的業(yè)務(wù)系統(tǒng),提升業(yè)務(wù)穩(wěn)定性。我們期望能夠分享更多幫助企業(yè)客戶上云、用好云,讓客戶云上業(yè)務(wù)運行更加穩(wěn)定可靠的技術(shù),您可用釘釘掃描下方二維碼,加入阿里云SRE技術(shù)學院釘釘圈子,和更多云上人交流關(guān)于云平臺的那些事。

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

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

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

您可能感興趣的文章:
  • Mysql的Binlog數(shù)據(jù)恢復(fù):不小心刪除數(shù)據(jù)庫詳解
  • MySQL數(shù)據(jù)庫運維之數(shù)據(jù)恢復(fù)的方法
  • Navicat for MySQL定時備份數(shù)據(jù)庫及數(shù)據(jù)恢復(fù)詳解
  • 詳解如何通過Mysql的二進制日志恢復(fù)數(shù)據(jù)庫數(shù)據(jù)
  • 關(guān)于mysql數(shù)據(jù)庫誤刪除后的數(shù)據(jù)恢復(fù)操作說明
  • 淺談mysqldump使用方法(MySQL數(shù)據(jù)庫的備份與恢復(fù))
  • mysql二進制日志文件恢復(fù)數(shù)據(jù)庫
  • 教你自動恢復(fù)MySQL數(shù)據(jù)庫的日志文件(binlog)

標簽:無錫 麗水 徐州 自貢 龍巖 西寧 迪慶 南充

巨人網(wǎng)絡(luò)通訊聲明:本文標題《Mysql數(shù)據(jù)庫按時間點恢復(fù)實戰(zhàn)記錄》,本文關(guān)鍵詞  Mysql,數(shù)據(jù)庫,按,時間,點,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《Mysql數(shù)據(jù)庫按時間點恢復(fù)實戰(zhàn)記錄》相關(guān)的同類信息!
  • 本頁收集關(guān)于Mysql數(shù)據(jù)庫按時間點恢復(fù)實戰(zhàn)記錄的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章