面試官：如果 MySQL 數(shù)據(jù)庫中的數(shù)據(jù)丟失，有哪些補救的辦法呢？

　　以前去企業(yè)面試的時候，經(jīng)常被問一些關(guān)于 MySQL 數(shù)據(jù)庫相關(guān)的問題，其中最典型的就是關(guān)于 MySQL 數(shù)據(jù)庫數(shù)據(jù)安全的問題。

　　例如：如何才能保證 MySQL 數(shù)據(jù)庫的數(shù)據(jù)安全？MySQL 數(shù)據(jù)庫如果發(fā)生數(shù)據(jù)丟失可能會發(fā)生在什么地方？如果 MySQL 數(shù)據(jù)庫出現(xiàn)了數(shù)據(jù)丟失該如何挽救？

　　問這些問題的主要目的就是考驗求職者的生產(chǎn)經(jīng)驗；但是就我面試的過程而言，能夠完整答出來的求職者微乎其微。

　　出現(xiàn)這種情況主要是因為大多數(shù)求職者對于 MySQL 數(shù)據(jù)庫底層數(shù)據(jù)存儲的運行機制了解得不夠清楚，那么今天我們就來針對于上述的幾個問題跟大家詳細討論一下 MySQL 數(shù)據(jù)庫的底層存儲運行機制。

　　在介紹 MySQL 數(shù)據(jù)庫在什么情況下可能會丟失數(shù)據(jù)之前，我們首先回顧一下寫入一條數(shù)據(jù)到 MySQL 數(shù)據(jù)庫中所經(jīng)歷的模塊，具體如下。第一個模塊：將修改的數(shù)據(jù)邏輯保存在 change buffer 之中。第二個模塊：將修改的數(shù)據(jù)保存在 binlog cache 之中。第三個模塊：將修改的數(shù)據(jù)保存在 redo log 之中。

　　在這三個模塊中，change buffer 是用來保存修改數(shù)據(jù)的邏輯的，在修改之后，通過 merge 的方式寫入磁盤。

　　在這個模塊中，有沒有可能發(fā)生數(shù)據(jù)丟失呢？其實微乎其微，這主要是因為 MySQL 數(shù)據(jù)庫為了防止數(shù)據(jù)丟失而增加了 redo log 這個模塊，其主要的作用就是防止數(shù)據(jù)丟失。那么，我們就一起來聊一聊 redo log 是怎么保存數(shù)據(jù)的。

　　redo log 主要分為兩個部分，分別是 redo log 和 redo log buffer 兩個部分。redo log 和 redo log buffer 的功能我們之前多次說過，這里不再贅述。下面我們主要介紹 redo log 是怎么保存數(shù)據(jù)的。

　　當一條數(shù)據(jù)寫入數(shù)據(jù)庫之前，為了防止數(shù)據(jù)丟失，首先會將該條數(shù)據(jù)保存在 redo log buffer 之中，然后再保存在 redo log 之中，以便當數(shù)據(jù)庫宕機之時作數(shù)據(jù)恢復(fù)使用。

　　那么這個時候我們就要問，在這個過程中 redo log 有沒有可能會發(fā)生數(shù)據(jù)丟失呢？

　　這是有可能的。假如一個事務(wù)在執(zhí)行一半的時候突然 MySQL 數(shù)據(jù)庫宕機，此時 redo log buffer 中的所有數(shù)據(jù)將會全部丟失，不過一般這種情況只會發(fā)生在事務(wù)未提交的情況下，所有數(shù)據(jù)丟失也影響不大。

　　此時，我相信你會問，如果恰好在事務(wù)提交之時，MySQL 數(shù)據(jù)庫發(fā)生宕機會不會丟失數(shù)據(jù)呢？

上海數(shù)據(jù)恢復(fù)

　　顯然，這也是有可能的。下面我們根據(jù) MySQL 數(shù)據(jù)庫保存 redo log buffer 中的數(shù)據(jù)來分析丟失數(shù)據(jù)的可能。

　　在 MySQL 數(shù)據(jù)庫中，redo log buffer 有三種保存數(shù)據(jù)的狀態(tài)，分別是：redo log buffer 將數(shù)據(jù)保存在 MySQL 數(shù)據(jù)庫的內(nèi)存中，也就是 InnoDB 存儲引擎的 buffer pool 之中。這其實跟上述的情況一致，保存的是未提交的數(shù)據(jù)，此時如果 MySQL 發(fā)生宕機，丟失的是未提交的事務(wù)信息，對于 MySQL 數(shù)據(jù)庫整體而言，沒有大的影響。redo log buffer 將數(shù)據(jù)保存在 page cache 之中，也就是磁盤緩存之中。此時 MySQL 中的事務(wù)已經(jīng)提交，假設(shè)恰巧運行 MySQL 數(shù)據(jù)庫的服務(wù)器在此時發(fā)生宕機，那么很顯然已經(jīng)提交的事務(wù)數(shù)據(jù)就會發(fā)生丟失。在這種情況下發(fā)生的數(shù)據(jù)丟失是無法恢復(fù)的。redo log buffer 將數(shù)據(jù)保存在磁盤之中，這種情況下一般只有磁盤不發(fā)生異常，是不會發(fā)生數(shù)據(jù)丟失的。

揚州數(shù)據(jù)恢復(fù)

　　注意：系統(tǒng)磁盤也是有緩存的，通常我們稱之為：page cacge。

　　MySQL 針對于redo log buffer保存數(shù)據(jù)的三種狀態(tài)又提供了名為innodb_flush_log_at_trx_commit的參數(shù)，這個參數(shù)有三個值，最主要的功能是告訴 MySQL 該將 redo log buffer 中的數(shù)據(jù)保存在哪里，具體如下：當該參數(shù)的值設(shè)置為 0 時，redo log buffer 將會把所有的數(shù)據(jù)保存在 buffer pool 之中；也就是全部保存在內(nèi)存之中，此時性能是最好的，但是一旦數(shù)據(jù)庫發(fā)生了重啟，redo log buffer 中的數(shù)據(jù)也就隨即全部丟失。當該參數(shù)的值設(shè)置為 1 時，redo log buffer 將會把所有的數(shù)據(jù)直接保存在磁盤之中，此時數(shù)據(jù)是最安全的，但是性能卻是最差的。當該參數(shù)的值設(shè)置為 2 時，redo log buffer 將會把所有的數(shù)據(jù)保存在 page cache 之中；也就是說會將數(shù)據(jù)全部保存在磁盤緩存之中，此時性能跟設(shè)置為 0 時的性能相差無幾，但是如果此時部署 MySQL 數(shù)據(jù)庫的服務(wù)器發(fā)生了宕機，數(shù)據(jù)也會隨即丟失。

　　注意：在實際的應(yīng)用中，也并非只有事務(wù)發(fā)生了提交，才會將數(shù)據(jù)保存到磁盤之中。還有如下兩種情況。

　　第一種情況：如果有多個事務(wù)并行之時，會將已經(jīng)保存在 redo log buffer 中的數(shù)據(jù)全部持久化。 第二種情況：如果 redo log buffer 占用 InnoDB 存儲引擎的 buffer pool 內(nèi)存空間的一半，MySQL 也會將數(shù)據(jù)持久化。

　　上面我們介紹了 redo log 可能會發(fā)生數(shù)據(jù)丟失的場景，下面我們再來了解一下 binlog 中可能發(fā)生數(shù)據(jù)丟失的情況。

　　相對于 redo log 來說，binlog 寫數(shù)據(jù)相對簡單。

　　首先需要說明的是，binlog 每一次寫入都是將整個事務(wù)同時寫入 binlog 文件中，這主要是因為 MySQL 數(shù)據(jù)庫中的事務(wù)具有原子性，所以在一個事務(wù)未執(zhí)行完成之前，MySQL 數(shù)據(jù)庫是將其寫入 binlog cache 之中。

　　其中 binlog cache 是 MySQL 中的一塊內(nèi)存空間，那么此時就帶來了一個新的問題，就是如果 binlog cache 的空間不足以承載某一個事務(wù)所包含的所有數(shù)據(jù)時，MySQL 會將該事務(wù)中所有的數(shù)據(jù)全部暫存到磁盤中（此時就會不得已而產(chǎn)生磁盤IO，隨即就會導(dǎo)致一定的性能問題）。

　　為了解決這個問題，MySQL 數(shù)據(jù)庫為我們提供了一個 binlog_cache_size 參數(shù)，這個參數(shù)主要是用來設(shè)置 binlog cache 的空間大小的。如果當 binlog cache 中的數(shù)據(jù)大小超過了 binlog_cache_size 設(shè)置的大小時，MySQL 會將該事務(wù)中所有的數(shù)據(jù)全部暫存到磁盤中。蘇州數(shù)據(jù)恢復(fù)

　　與 redo log 相同的是，binlog cache 也有保存數(shù)據(jù)的三種狀態(tài)，并且 MySQL 提供了 sync_binlog 這個參數(shù)來控制這種狀態(tài)。這三種狀態(tài)分別是：當該值等于 0 時，每次事務(wù)提交之后，保存在 page cache；當該值等于 1 時，每次事務(wù)提交之后，保存到磁盤之中；當該值等于 N（N > 1） 時，每次事務(wù)提交之后，都會保存在 page cache 之中，并且累計 N 次之后寫入磁盤。

　　于是，我們不難看出，當 N 越大時，相關(guān)的性能就會越好；相反，如果在數(shù)據(jù)提交期間發(fā)生了數(shù)據(jù)庫宕機，隨即帶來的后果就是會丟失保存在 binlog cache 中的數(shù)據(jù)。

　　今天，我們主要介紹了在 MySQL 數(shù)據(jù)庫運行過程中可能會發(fā)生數(shù)據(jù)丟失的幾種情況。

　　首先是 redo log，在 redo log 中最可能丟失數(shù)據(jù)的情況就是當 redo log buffer 中的數(shù)據(jù)保存在 MySQL 內(nèi)存之中，也就是當

　　innodb_flush_log_at_trx_commit 設(shè)置成 0 時；所以，為了安全和性能兩個方面考慮，建議將其設(shè)置成 2， 一般 MySQL 重啟，而部署 MySQL 的服務(wù)器不會重啟。

　　其次是 binlog，與 redo log相同的是 binlog 也有三種保存數(shù)據(jù)的狀態(tài)，同樣為了安全和性能兩個方面考慮，我建議你將 sync_binlog 設(shè)置成 N。

　　在日常的生產(chǎn)環(huán)境之中，一般會將 sync_binlog 設(shè)置為：100 ~ 1000 之間，具體要看服務(wù)器性能，如果服務(wù)器的內(nèi)存有空余，可以將其按需調(diào)大。

　　作者：Mche鏈接：

　　https://juejin.cn/post/7188423924894400569來源：稀土掘金