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

　　以前去企業面試的時候，經常被問一些關于 MySQL 數據庫相關的問題，其中最典型的就是關于 MySQL 數據庫數據安全的問題。

　　例如：如何才能保證 MySQL 數據庫的數據安全？MySQL 數據庫如果發生數據丟失可能會發生在什么地方？如果 MySQL 數據庫出現了數據丟失該如何挽救？

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

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

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

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

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

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

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

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

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

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

上海數據恢復

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

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

揚州數據恢復

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

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

　　注意：在實際的應用中，也并非只有事務發生了提交，才會將數據保存到磁盤之中。還有如下兩種情況。

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

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

　　相對于 redo log 來說，binlog 寫數據相對簡單。

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

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

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

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

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

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

　　首先是 redo log，在 redo log 中最可能丟失數據的情況就是當 redo log buffer 中的數據保存在 MySQL 內存之中，也就是當

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

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

　　在日常的生產環境之中，一般會將 sync_binlog 設置為：100 ~ 1000 之間，具體要看服務器性能，如果服務器的內存有空余，可以將其按需調大。

　　作者：Mche鏈接：

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