<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          即使刪了全庫,如何半小時恢復(fù)?

          共 1627字,需瀏覽 4分鐘

           ·

          2021-05-20 00:32

          技術(shù)人如果經(jīng)常線上操作DB,河邊走久了,難免出現(xiàn)紕漏:
          (1)update錯數(shù)據(jù)了;
          (2)delete錯數(shù)據(jù)了;
          (3)drop錯數(shù)據(jù)了;
          咋辦?找DBA恢復(fù)數(shù)據(jù)唄,即使恢復(fù)不了,鍋總得有人背呀。
          畫外音:把數(shù)據(jù)全刪了,怎么辦,怎么辦?

          零,哪種方案不能實現(xiàn)數(shù)據(jù)恢復(fù)?
          從“從庫”恢復(fù)數(shù)據(jù)。

          一般來說數(shù)據(jù)庫集群是主從架構(gòu):
          如果人為執(zhí)行了“刪庫”操作,命令會同步給其他從庫,導(dǎo)致所有庫上的數(shù)據(jù)全被刪除,無法恢復(fù),故這種方案是不行的。

          一,如果DBA沒有做功課,最常見的處理方案是什么?
          如果沒有做數(shù)據(jù)安全方案,應(yīng)對“刪庫”最常見的操作是,跑路。刪掉了公司最重要的資產(chǎn),還不快閃。
           
          二,如果DBA日常做了全量備份+增量備份,應(yīng)該怎么處理?
          DBA最常見的技能是:全量備份+增量備份。


          全量備份:定期(例如一個月)將庫文件全量備份。
           

          增量備份:定期(例如每天)將binlog增量備份。
           
          如果不小心“刪庫”,可以這么恢復(fù):
          (1)將最近一次全量備份的全庫找到,拷貝回來(文件一般比較大),解壓,應(yīng)用;
          (2)將最近一次全量備份后,每一天的增量binlog找到,拷貝回來(文件較多),依次重放;
          (3)將最近一次增量備份后,到執(zhí)行“刪全庫”之前的binlog找到,重放;
          恢復(fù)完畢。

          為了保證方案的可靠性,需要定期進行演練。

          咦,我怎么好像沒聽過DBA定期做過這類演練?
          很有可能只是做了理論上的方案,如果真出了問題,效果也只是理論上能恢復(fù)。此時回歸方案一,跑路。

          全量備份+增量備份的恢復(fù)周期也非常長,可能是天級別。
          畫外音:把幾T的數(shù)據(jù)傳輸過來都用了好長時間。
           
          三,如果DBA做了“1小時延時從庫”,應(yīng)該怎么處理?


          什么是1小時延時從庫?
          如上圖所示,增加一個從庫,這個從庫不是實時與主庫保持同步的,而是每隔1個小時同步一次主庫,同步完之后立馬斷開1小時,這個從庫會與主庫保持1個小時的數(shù)據(jù)差距。

          當(dāng)“刪全庫”事故發(fā)生時,如何利用“1小時延時從庫”快速恢復(fù)數(shù)據(jù)?
          (1)應(yīng)用1小時延時從;
          (2)將1小時延時從最近一次同步時間到,執(zhí)行“刪全庫”之前的binlog找到,重放
          快速恢復(fù)完畢。
           
          這個方案的優(yōu)點是,能夠快速找回數(shù)據(jù)。潛在不足是,萬一“1小時延時從庫”正在連上主庫進行同步的一小段時間內(nèi),發(fā)生了“刪庫”事故,也無法恢復(fù)。
           
          四,如果DBA做了“雙份1小時延時從庫”,應(yīng)該怎么處理?

          什么是雙份1小時延時從?
          如上圖所示,兩個1小時延時從庫,它們連主庫同步數(shù)據(jù)的時間“岔開半小時”。

          這樣,即使一個延時從連上主庫進行同步的一小段時間內(nèi),發(fā)生了“刪庫”事故,依然有另一個延時從保有半小時之前的數(shù)據(jù),可以實施快速恢復(fù)。
           
          這個方案的優(yōu)點是,沒有萬一,一定能快速恢復(fù)數(shù)據(jù)。潛在的不足是,資源利用率有點低,為了保證數(shù)據(jù)的安全性,多了2臺延時從,降低了從庫利用率。
           
          如何提高從庫利用效率?

          對于一些“允許延時”的業(yè)務(wù),可以使用1小時延時從,例如:
          (1)運營后臺,產(chǎn)品后臺;
          (2)BI進行數(shù)據(jù)同步;
          (3)研發(fā)進行數(shù)據(jù)抽樣,調(diào)研;
          但需要注意的是,畢竟這是從庫,只能夠提供“只讀”服務(wù)喲。
           
          五,總結(jié)
          保證數(shù)據(jù)的安全性是DBA第一要務(wù):
          (0)理論上可以恢復(fù)+跑路;
          (1)全量備份+增量備份+定期演練;
          (2)1小時延時從庫;
          (3)雙份1小時延時從庫+提高資源利用率;

          相關(guān)推薦:
          InnoDB并發(fā)如此高,原因竟然在這?
          InnoDB七種鎖
          InnoDB索引,終于懂了
          InnoDB,四種事務(wù)的隔離級別實現(xiàn)
          InnoDB,調(diào)試死鎖的方法!

          DBA的神技能,學(xué)到了嗎,求轉(zhuǎn)。

          調(diào)研
          貴司用的是哪種方案?
          瀏覽 36
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  91av在线无码 | 国产视频黄色 | 草久久免费视频 | 诱咪一区二区三区四区 | 大香蕉日韩在线 |