點擊右邊

MySQL數據規復的九百家樂 英文把瑞士軍刀

線上麻將連線

《MySQL數據規復的九把瑞士軍刀》要點:
本文先容了MySQL數據規復的九把瑞士軍刀,但愿對您有效。若是有疑難,可以接洽咱們。

作者先容

李輝,新浪愛彩票運維擔任人,經常使用網名:門牙沒了.主導新浪愛彩票的MySQL運維事情.培訓合伙人、資深講師,中國迷信院大學在讀研究生(大數據偏向),善于大型項目的瓜葛型數據庫運維以及治理,目前在數據庫運維主動化偏向研究.

做DBA的同伙可能都碰到過MySQL數據破壞或者丟掉的成績,譬如忘加where前提的update、delete語句,或者者MySQL服務器異樣宕機致使數據文件破壞等.本文針對在一樣平常運維中因為誤操作、數據文件破壞、硬盤破壞、備份掉效等環境致使的種種數據丟掉或者破壞的場景,供應了九種規復方案,供人人參考.

注:高危操作請勿在沒有測試的環境下,間接在臨盆情況使用.

對象一:齊全備份+binlog

規復數據最多見的做法,只需有這兩樣器材,無論是誤操作仍是數據庫破壞等,都能規復數據到指定的時間節點,能籠罩大多半的規復場景,也是DBA手中最緊張的資產.規復要領比較簡略這里就無非多贅述了.

對象二:營業邏輯反推規復update誤操作

這類要領得當做了誤操作但停機遇形成更大影響的場景,經由過程邏輯反推可以敏捷規復數據到正常狀況.上面咱們以用戶充值表為例,來望望若何規復誤操作.

充值狀況申明:0未充值,1已經充值,2充值掉敗,3充值異樣.

示例1:

某開發在處置用戶充值故障時漏失了用戶id,致使大面積的用戶充值狀況被改動.因為此表中有last_update_time字段,以是咱們可以依據最初點竄時間規復此次的誤操作.

  • 精確的語句update t1 set status=1 where member_id=10001 and status=0;
  • 誤操作語句update t1 set status=1 where status=0;
  • 反向履行即可規復誤操作update t1 set status=0 where status=1 and last_update_time=’2017-03-20 11:30:27’;

示例2:

某開發在處置用戶充值狀況時,漏失了where前提,致使全表被更新.

  • 精確的語句update t1 set status=1 where member_id=10001 and status=0;
  • 誤操作語句update t set status=1;

履行時丟掉了where前提,此時就要依據別的表中記載的用戶最初的充值status來進行規復了,譬如用戶充值汗青表,先從用戶充值汗青表中獲得用戶最初一次充值的記載,闡發這次充值的status,規復到用戶充值表即可.這類規復要領以及營業邏輯親近相關.

從這里咱們也能夠望出此要領并不是很謹嚴,比較得當小范圍的規復.

對象三:MySQL flashback

最早的相關材料是在彭立勛的博客上,隨后他提交給了MariaDB,網易等大樂透加碼大廠在本人的分支中也完成了該功效.關于依然在使用民間支流版本的同窗來說,業內開源的mysqlbinlog_flashback以及binlog2sql這兩個閃歸對象是個不錯的選擇,作者已經經在Github上開源.

其道理首要是因為binlog中會記載Update以及Delete語句在變動先后的一切狀況(以下圖),對binlog進行剖析以及處置即可失去原始SQL、歸滾SQL、INSERT539連碰中獎金額語句等,可以規復Update以及Delete誤操作.

對象四:innodb_force_recovery

MySQL非正常重啟或者者磁盤故障等緣故原由可能致使MySQL數據文件破壞,破壞后會致使MySQL server沒法啟動.若是也沒有備份文件,可以使用這個選項強迫InnoDB啟動,制止一些后臺操作的運轉,從而dump出數據庫中的數據.

innodb_force_recovery可選的值為0-6,默許環境下的值為0,大的數字包括后面一切數字的影響.當配置參數值大于0后,可以對表進行select,create,drop操作,但insert,update或者者delete這種操作是不許可的.

  1. SRV_FORCE_IGNORE_CORRUPT:忽略反省到的corrupt頁
  2. SRV_FORCE_NO_BACKGROUND:制止主線程的運轉,如主線程必要履行full purge操作,會致使crash
  3. SRV_FORCE_NO_TRX_UNDO:不履行事務歸滾操作
  4. SRV_FORCE_NO_IBUF_MERGE:不履行拔出緩沖的歸并操作
  5. SRV_FORCE_NO_UNDO_LOG_SCAN:不查望重做日記,InnoDB存儲引擎會將未提交的事務視為已經提交
  6. SRV_FORCE_NO_LOG_REDO:不履行前滾的操作.

[mysqld]中參加此參數,測驗考試啟動MySQL,若是啟動掉敗就慢慢增長參數的值,直到啟動為止,當然其數據一致性也會愈來愈差.數據庫啟動后,InnoDB類型的表只能讀不克不及寫,此時把表中的數據dump進去,或者導入MyISAM內外面,即可規復破壞的數據.

對象五:DISCARD、IMPORT TABLESPACE

這類要領實用于修復frm文件破壞,或者者誤操作、ibd破壞然則有物理備份的環境.修單數據要分兩種環境接頭:

  • 有物理備份,數據破壞后table沒有recreate過

這類環境下規復是比較簡略的,物理備份中的ibd、數據庫中ibd的space id以及index id,都是以及ibdata文件中的space id以及index id一致的,以是可以間接拿物理備份中的ibd籠罩數據庫中的ibd.

操作進程:

  1. 運用物理備份的log:innobackupex –apply-log
  2. 備份數據庫中的ibd:cp test.ibd test.bak
  3. 丟棄數據庫中的ibd:alter table test discard tablespace;
  4. 復制物理備份中的ibd到數據庫目次:cp /bak/test.ibd /data/test/; chown mysql:mysql /data/test/tes玩運彩t.ibd
  5. 導入ibd:alter table test import tablespace;
  • 有物理備份,然則數據庫中表布局已經經被drop.

這類環境有點龐大,由于表被drop后元數據中的space id以及index id已經經被刪除.但space id以及index id會留空,不會被新創立的table占用,給咱們留下了規復的機遇.只要要重修表布局,然后在ibdata中還原該表的space id即可,還原進程必要percona recovery tool的幫忙.

操作進程:

  1. 運用物理備份的log:innobackupex –apply-log
  2. 數據庫中重修表:create table test(id int);
  3. 封閉數據庫
  4. 用物理備份中的ibd籠罩數據庫中的ibd
  5. 使用percona recovery tool點竄ibdata:~/percona-data-recovery-tool-for-innodb-0.5/ibdconnect -o /data/ibdata1 -f /data/test/test.ibd -d test -t test
  6. 使用percona recovery tool對ibdata做checksum:~/percona-data-recovery-tool-for-i大樂透端午加碼nnodb-0.5/innochecksum -f /data/ibdata1
  7. 反復履行履行步調6,直到沒有任何輸入為止
  8. 啟動MySQL

對象六:手工點竄ibd

這類要領實用于只有ibd文件以及表布局了,frm以及ibdata掃數破壞的環境.其道理是在新數據庫上創立表,然后點竄待規復的ibd的文件頭,使之順應新表的space id以及index id,從而讀掏出ibd中的數據.

操作進程:

一、新建數據庫,創立必要規復的數據庫的表布局.

2、使用vim關上此表的ibd文件,16進制查望.

三、使用vim關上要規復的ibd文件,16進制查望

四、點竄要規復的ibd文件,將紅方框中的值點竄的以及方才創立的新表的ibd文件一致.望到前面大段的0000沒,咱們只要要點竄文件頭就可以了.00000c0偏移量之后的不消點竄.

五、把待規復的ibd文件籠罩方才創立的新表的ibd文件.點竄文件權限為MySQL用戶.

6、重啟MySQL,重啟時加上參數innodb_force_recovery.

七、將數據dump進去,找歸數據勝利.

對象七:extundelete

【免責聲明】本站內容轉載自互聯網,其相關談吐僅代表作者小我私家概念盡非權勢巨子,不代表本站態度。如您發明內容存在版權成績,請提交相關鏈接至郵箱:,咱們將實時予以處置。