1、起因

時(shí)間：2022.03.12 10:10。

事件：網(wǎng)站的 mariadb 數(shù)據(jù)庫 server 突然崩潰，嘗試各種辦法啟動(dòng)無果。

過程：不幸的是數(shù)據(jù)庫沒有備份，萬幸的是可以通過數(shù)據(jù)庫物理文件恢復(fù)數(shù)據(jù)。

結(jié)果：恢復(fù)數(shù)據(jù)，并特此記錄整個(gè)過程，以備急時(shí)之需。

2、數(shù)據(jù)庫與數(shù)據(jù)文件

眾所周知，數(shù)據(jù)庫中的數(shù)據(jù)會(huì)以文件的形式落盤進(jìn)行保存(這些文件是以某種特定格式存儲(chǔ)的，不是text格式，試圖用文本編輯器打開會(huì)看到亂碼)。在數(shù)據(jù)庫中，每一個(gè) database 都是一個(gè)單獨(dú)的文件夾，文件夾下存儲(chǔ)著每一張表的相關(guān)文件(不同的存儲(chǔ)引擎生成的表文件可能不同，這里使用 innodb 引擎)。

例如，筆者網(wǎng)站數(shù)據(jù)庫名稱叫做 ivansli，有一個(gè)用戶表 - user，脫敏之后的數(shù)據(jù)文件布局大致如下：

?  /usr/local/data tree -L 2                    
.
├── aria_log.00000001
├── aria_log_control
├── ib_buffer_pool
├── ibdata1
├── ib_logfile0
├── ibtmp1
├── iZuf63yp8w5ku4znrskda8Z.err
├── iZuf63yp8w5ku4znrskda8Z.pid
├── multi-master.info
├── mysql-bin.000001
├── mysql-bin.000002
├── mysql-bin.000003
├── mysql-bin.index
├── mysql-slow.log
├── performance_schema
│   └── db.opt
└── ivansli
    ├── db.opt
    ├── user.frm
    ├── user.MYD
    └── user.MYI

這里的 /usr/local/data 數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)的目錄。

ivansli文件夾下可以看到有三個(gè)不同格式，相同名稱的文件，作用分別為：user.frm，存儲(chǔ)數(shù)據(jù)表的元數(shù)據(jù) user.MYD，存儲(chǔ)數(shù)據(jù)表的具體數(shù)據(jù) user.MYI，存儲(chǔ)數(shù)據(jù)表的索引。

除了每張表的若干個(gè)文件之外，對(duì)于數(shù)據(jù)庫server來說還有一個(gè)重要的 ibdata1 文件(位于數(shù)據(jù)庫 server 存儲(chǔ)數(shù)據(jù)的根目錄)。

3、 ibdata 作用

ibdata (是InnoDB基礎(chǔ)結(jié)構(gòu)的系統(tǒng)表空間) 包含幾個(gè)對(duì)InnoDB至關(guān)重要的信息:

• 表格數(shù)據(jù)頁。
• 表索引頁。
• 數(shù)據(jù)字典。
• MVCC控制數(shù)據(jù)。

撤消空間、回滾段

• 雙重寫入緩沖區(qū)(在后臺(tái)寫頁面以避免操作系統(tǒng)緩存)。
• 插入緩沖區(qū)(對(duì)二級(jí)索引的更改)。

筆者這里 innodb_file_per_table=0，使用共享表空間 ibdata1，所以恢復(fù)數(shù)據(jù)時(shí)需要拷貝這個(gè)文件 關(guān)于這個(gè)文件具體可以查閱相關(guān)資料。

對(duì)于筆者來說，雖然 數(shù)據(jù)庫 server 掛了，但是這些關(guān)鍵性的文件還是完整的。那么，就有辦法通過這些文件來恢復(fù)對(duì)應(yīng)的數(shù)據(jù)。

舉個(gè)不太恰當(dāng)?shù)睦樱?/p>

這里的數(shù)據(jù)恢復(fù)有點(diǎn)像器官移植，器官捐獻(xiàn)者可能已經(jīng)大腦死亡。

但是捐獻(xiàn)者的心臟等器官還是有活力的，找到適合的目標(biāo)受體，這些器官還是能夠繼續(xù)工作的。

4、 恢復(fù)過程

這里以 ivansli database 數(shù)據(jù)庫的恢復(fù)為例，整個(gè)恢復(fù)過程大致如下：

（1）查看當(dāng)前待恢復(fù)的數(shù)據(jù)所在的 server(這里稱為 源數(shù)據(jù)庫server) 類型以及版本 筆者這里使用的是 mariadb - 10.7.0。

為什么要看已經(jīng) crash 掉的數(shù)據(jù)庫 server 的類型、版本呢?

主要是為數(shù)據(jù)恢復(fù)找到一個(gè)匹配的環(huán)境(類比器官移植，也是需要找到相同、相近的匹配受體，否則就會(huì)出問題)。

（2）在其他服務(wù)器搭建 與 源數(shù)據(jù)庫server 相同或者相近版本的 數(shù)據(jù)庫server (這里稱為 目標(biāo)數(shù)據(jù)庫server) 搭建好之后，先把 目標(biāo)數(shù)據(jù)庫server 停掉，暫時(shí)不啟動(dòng)，為后面拷貝數(shù)據(jù)做準(zhǔn)備。

（3）把 源數(shù)據(jù)庫server 待恢復(fù)的文件夾(這里是 ivansli 文件夾)與 ibdata1 文件拷貝到 目標(biāo)數(shù)據(jù)庫server 數(shù)據(jù)目錄下 ivansli 文件夾在 目標(biāo)數(shù)據(jù)庫server 數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)目錄下不存在，直接拷貝。ibdata1 文件在 目標(biāo)數(shù)據(jù)庫server 數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)目錄下有同名文件，直接覆蓋。

（4）修改 目標(biāo)數(shù)據(jù)庫server 數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)目錄下相關(guān)文件權(quán)限。

chmod -R 660 ivansli ibdata1
 chown -R mysql:mysql ivansli ibdata1
 chmod +x ivansli

（5）啟動(dòng) 目標(biāo)數(shù)據(jù)庫server。

（6）使用 root 賬號(hào)登錄 目標(biāo)數(shù)據(jù)庫server，查看數(shù)據(jù)恢復(fù)情況。

（7）目標(biāo)數(shù)據(jù)庫server上 能夠看到待恢復(fù)數(shù)據(jù)，做數(shù)據(jù)備份導(dǎo)出保存。

（8）在 源數(shù)據(jù)庫server 服務(wù)器上搭建新的 數(shù)據(jù)庫server，把恢復(fù)的數(shù)據(jù)導(dǎo)入進(jìn)來。

5、 總結(jié)

對(duì)于開發(fā)人員來說，會(huì)經(jīng)常聽到刪庫跑路、刪庫坐牢之類的事情發(fā)生。對(duì)于公司來說，最重要的是用戶的數(shù)據(jù)信息，尤其是金融等行業(yè)，寧可服務(wù)不可用，數(shù)據(jù)安全是一定要保證的。

這篇文章所描述的是在數(shù)據(jù)文件存在的特定情況下進(jìn)行簡單的數(shù)據(jù)恢復(fù)。對(duì)于數(shù)據(jù)文件被刪除掉的情況，可能要進(jìn)行掃描磁盤等更專業(yè)的操作了。

總之一句話：善待每一行代碼，謹(jǐn)慎敲打每一個(gè)命令。還有就是：做好數(shù)據(jù)備份、做好數(shù)據(jù)備份、做好數(shù)據(jù)備份。