MySQL數據庫無完整備份刪庫,除了跑路還能怎麼辦?

1.背景

前段時間,因爲運維同事的一次誤操做,清空了內網核心數據庫,致使了公司內部管理系統長時間不可用,大量知識庫內容因爲沒有備份險些丟失。html

結合這兩天微盟的刪庫跑路事件,咱們能夠看到,數據庫的備份與恢復顯得尤其重要。mysql

本文將對這次內網數據恢復過程作一些整理,介紹刪庫後的搶救方案。git

同時,引起對數據庫穩定性的思考。github

 

MySQL數據庫無完整備份刪庫,除了跑路還能怎麼辦?

 

 

2.數據搶修

這分內網數據事先沒有特地備份,因此一開始認爲須要從磁盤恢復數據了。因此緊急聯繫了數據恢復公司,但願過來恢復磁盤數據。面試

這裏須要注意,數據恢復公司建議立刻關機,避免磁盤數據被覆蓋。sql

聯繫數據恢復公司的同時,運維同事在內網找到了幾個殘缺的備份文件,包括去年4月份的一個全量備份數據、今年2月初一個半全量備份數據(備份到r開頭的表就失敗了,剩餘表沒有備份),以及近7天到binlog日誌文件。數據庫

因此馬上進行另外一套恢復方案:安全

1)用今年2月初的半全量數據恢復一個庫A網絡

2)用去年4月份的全量數據恢復一個庫B運維

3)將B數據庫中r開頭以後的表拷貝一份到數據庫A中

4)數據庫A中重放近3天的binlog。(注意,binlog回放時間截止到drop命令時間以前)

2.1 dump文件恢復

一開始想經過阿里雲,把dump文件恢復到rds上。

結果發現須要super權限,而這個權限是阿里雲高權限帳號(另外還有普通帳號)也不具有的,問了阿里雲也不提供。所以,沒法恢復到rds。

因此咱們只能把dump文件恢復到本地數據庫。

在ECS上創建一個mysql數據庫,而後就是dump文件恢復。

有兩種方式:

1)命令行恢復

mysql -u root xxxdb < xxxx-backup.sql

2)在mysql客戶端中恢復

用root登錄後

use xxxdb;

source /data/xxxx-backup.sql

2.2 binlog文件重放恢復

基於起止時間恢復數據

sudo mysqlbinlog --start-datetime="2020-02-16 17:00:01" --stop-datetime="2020-02-20 17:00:00" —database=xxxdb mysql-bin.000218 | mysql -f -u root xxxdb

--database 指定了使用binlog中的哪一個數據庫進行導入,不然,若是binlog中有多個庫的操做記錄,會大量報錯。

更多binlog命令參數見:

https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_database

-f 用於mysql命令,重建過程當中若是遇到問題會繼續執行而不是中斷退出。

Actually mysqlbinlog does not stop after error, mysqlbinlog just converts log file to text format, nothing more. The problem is that mysql client stops after error. Please try 'mysql -f'.

3 數據備份

數據備份能夠有多種方式,這裏介紹三種

3.1 本地dump備份數據文件

比較方便存儲,不過用起來限制也比較多,容易中斷。

mysqldump --max_allowed_packet=1024M -u root xxxxdv > 20200219.sql

3.2 阿里雲dts遷移備份

能夠在阿里雲上建一個dts遷移任務(遷移任務基本免費,同步任務收費),而後經過dts將源數據庫直接遷移到rds、ecs自建數據庫、vpc網絡下到自建數據等地方。

能夠避免dump還原的過程。

須要有個目標庫,備份不是以簡單的數據文件形式,而是一個備份數據庫的形式。

3.3 xtrabackup(簡稱xbk)

https://www.percona.com/software/mysql-database/percona-xtrabackup

基於拷貝物理文件和redo來實現備份。

4. 數據庫穩定性思考

不論是運維的誤操做,仍是像微盟這樣的惡性事件,從根本上反映了企業數據庫穩定性管理的不足。

任何過後搶救的措施,都比不上事前的謹慎防範。

如何提升企業數據庫的穩定性,避免出現相似這樣的事情呢?

1)統一技術棧,使用雲廠商的雲數據庫

從如今雲技術的發展來看,以阿里雲、華爲雲等大廠提供的雲數據庫,能大大下降企業數據庫的運維成本。

雖然雲數據庫可能比自建數據庫的價格貴一點,可是,雲數據庫提供的完整的配套設施,如備份恢復、監控報警、技術支持、數據庫高可用等,都會給企業數據庫穩定性帶來巨大幫助。從長期來看,可以大大節約企業的運維成本和人力成本。

另外,我特地去看了下阿里雲的rds數據庫,有完整的備份恢復機制,並且七天內的備份數據是不可刪除的。

因此,若是使用了雲數據庫,那基本上不須要擔憂數據丟失或者被人惡習刪除的問題了。

2)自建數據庫的完善備份機制

固然,有的公司雖然使用了雲數據庫,可是出於數據安全性的角度,仍是會有自建數據庫的可能。

若是使用了自建數據庫,那麼必定須要有完善的備份機制。

我司自從發生了誤操做刪除內網數據的事件後,馬上引發重視,從新盤點梳理了核心數據的備份機制,包括雲數據庫、自建數據庫,對於核心數據(包括但不限於生產數據、內部核心數據等)必須實施按期全量備份,同時考慮末日容災,實施跨機房、跨雲廠商的數據備份。

3)更健全的權限管理系統

除了數據備份外,咱們還能夠看到,數據庫權限管理的重要性。

尤爲中小企業,數據庫權限要麼沒有管理,開發人員能夠任意操做;要麼是集中在少數幾個運維同事手上。

不管哪一種,都不安全。

最好的方式,仍是開發一個統一數據庫管理操做平臺(或者購買相似阿里雲DMS產品),在系統層面進行數據庫的權限管控。

全部人員都只能經過這個平臺操做數據庫,同時,禁用危險命令,對高危操做進行分級審覈。

 

看到這裏了,原創不易,點個關注、點個贊吧,你最好看了~

知識碎片從新梳理,構建Java知識圖譜:https://github.com/saigu/JavaKnowledgeGraph(歷史文章查閱很是方便)

掃碼關注個人公衆號「阿丸筆記」,第一時間獲取最新更新。同時能夠免費獲取海量Java技術棧電子書、各個大廠面試題。

阿丸筆記

相關文章
相關標籤/搜索