MySQL資料庫無完整備份删庫，除了跑路還能怎麼辦？

1.背景

前段時間，由于運維同僚的一次誤操作，清空了内網核心資料庫，導緻了公司内部管理系統長時間不可用，大量知識庫内容由于沒有備份險些丢失。

結合這兩天微盟的删庫跑路事件，我們可以看到，資料庫的備份與恢複顯得尤為重要。

本文将對此次内網資料恢複過程做一些整理，介紹删庫後的搶救方案。

同時，引發對資料庫穩定性的思考。

2.資料搶修

這份内網資料事先沒有特意備份，是以一開始認為需要從磁盤恢複資料了。是以緊急聯系了資料恢複公司，希望過來恢複磁盤資料。

這裡需要注意，資料恢複公司建議馬上關機，避免磁盤資料被覆寫。

聯系資料恢複公司的同時，運維同僚在内網找到了幾個殘缺的備份檔案，包括去年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指令參數見:

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)

www.percona。com/software/mysql-database/percona-xtrabackup

基于拷貝實體檔案和redo來實作備份。

1. 資料庫穩定性思考

不管是運維的誤操作，還是像微盟這樣的惡性事件，從根本上反映了企業資料庫穩定性管理的不足。

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

如何提高企業資料庫的穩定性，避免出現類似這樣的事情呢？

1）統一技術棧，使用雲廠商的雲資料庫

從現在雲技術的發展來看，以阿裡雲、華為雲等大廠提供的雲資料庫，能大大降低企業資料庫的運維成本。

雖然雲資料庫可能比自建資料庫的價格貴一點，但是，雲資料庫提供的完整的配套設施，如備份恢複、監控報警、技術支援、資料庫高可用等，都會給

遊戲交易

企業資料庫穩定性帶來巨大幫助。從長期來看，能夠大大節約企業的運維成本和人力成本。

另外，我特意去看了下阿裡雲的rds資料庫，有完整的備份恢複機制，而且七天内的備份資料是不可删除的。

是以，如果使用了雲資料庫，那基本上不需要擔心資料丢失或者被人惡習删除的問題了。

2）自建資料庫的完善備份機制

當然，有的公司雖然使用了雲資料庫，但是出于資料安全性的角度，還是會有自建資料庫的可能。

如果使用了自建資料庫，那麼一定需要有完善的備份機制。

我司自從發生了誤操作删除内網資料的事件後，立刻引起重視，重新盤點梳理了核心資料的備份機制，包括雲資料庫、自建資料庫，對于核心資料（包括但不限于生産資料、内部核心資料等）必須實施定期全量備份，同時考慮末日容災，實施跨機房、跨雲廠商的資料備份。

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

除了資料備份外，我們還可以看到，資料庫權限管理的重要性。

尤其中小企業，資料庫權限要麼沒有管理，開發人員可以任意操作；要麼是集中在少數幾個運維同僚手上。

無論哪種，都不安全。

最好的方式，還是開發一個統一資料庫管理操作平台（或者購買類似阿裡雲DMS産品），在系統層面進行資料庫的權限管控。

所有人員都隻能通過這個平台操作資料庫，同時，禁用危險指令，對高危操作進行分級稽核。