為了數(shù)據(jù)安全，數(shù)據(jù)庫需要定期備份，這個大家都懂，然而數(shù)據(jù)庫備份的時候，最怕寫操作，因為這個最容易導致數(shù)據(jù)的不一致，松哥舉一個簡單的例子大家來看下：

假設在數(shù)據(jù)庫備份期間，有用戶下單了，那么可能會出現(xiàn)如下問題：

• 庫存表扣庫存。
• 備份庫存表。
• 備份訂單表數(shù)據(jù)。
• 訂單表添加訂單。
• 用戶表扣除賬戶余額。
• 備份用戶表。

如果按照上面這樣的邏輯執(zhí)行，備份文件中的訂單表就少了一條記錄。將來如果使用這個備份文件恢復數(shù)據(jù)的話，就少了一條記錄，造成數(shù)據(jù)不一致。

為了解決這個問題，MySQL 中提供了很多方案，我們來逐一進行講解并分析其優(yōu)劣。

1. 全庫只讀

要解決這個問題，我們最容易想到的辦法就是在數(shù)據(jù)庫備份期間設置數(shù)據(jù)庫只讀，不能寫，這樣就不用擔心數(shù)據(jù)不一致了，設置全庫只讀的辦法也很簡單，首先我們執(zhí)行如下 SQL 先看看對應變量的值：

show variables like 'read_only';

可以看到，默認情況下， read_only 是 OFF，即關閉狀態(tài)，我們先把它改為 ON，執(zhí)行如下 SQL：

set global read_only=1;

1 表示 ON，0 表示 OFF，執(zhí)行結果如下：

這個 read_only 對 super 用戶無效，所以設置完成后，接下來我們退出來這個會話，然后創(chuàng)建一個不包含 super 權限的用戶，用新用戶登錄，登錄成功之后，執(zhí)行一個插入 SQL，結果如下：

可以看到，這個錯誤信息中說，現(xiàn)在的 MySQL 是只讀的（只能查詢），不能執(zhí)行當前 SQL。

加了只讀屬性，就不用擔心備份的時候發(fā)生數(shù)據(jù)不一致的問題了。

但是 read_only 我們通常用來標識一個 MySQL 實例是主庫還是從庫：

• read_only=0，表示該實例為主庫。數(shù)據(jù)庫管理員 DBA 可能每隔一段時間就會對該實例寫入一些業(yè)務無關的數(shù)據(jù)來判斷主庫是否可寫，是否可用，這就是常見的探測主庫實例是否活著的。
• read_only=1，表示該實例為從庫。每隔一段時間探活，往往只會對從庫進行讀操作，比如select 1;這樣進行探活從庫。

所以， read_only 這個屬性其實并不適合用來做備份，而且如果使用了 read_only 屬性將整個庫設置為 readonly 之后，如果客戶端發(fā)生異常，則數(shù)據(jù)庫就會一直保持 readonly 狀態(tài)，這樣會導致整個庫長時間處于不可寫狀態(tài)，風險很高。

因此這種方案不合格。

2. 全局鎖

全局鎖，顧名思義，就是把整個庫鎖起來，鎖起來的庫就不能增刪改了，只能讀了。

那么我們看看怎么使用全局鎖。MySQL 提供了一個加全局讀鎖的方法，命令是 flush tables with read lock (FTWRL)。當你需要讓整個庫處于只讀狀態(tài)的時候，可以使用這個命令，之后其他線程的增刪改等操作就會被阻塞。

從圖中可以看到，使用 flush tables with read lock; 指令可以鎖定表；使用 unlock tables; 指令則可以完成解鎖操作（會話斷開時也會自動解鎖）。

和第一小節(jié)的方案相比，F(xiàn)TWRL 有一點進步，即：執(zhí)行 FTWRL 命令之后如果客戶端發(fā)生異常斷開，那么 MySQL 會自動釋放這個全局鎖，整個庫回到可以正常更新的狀態(tài)，而不會一直處于只讀狀態(tài)。

但是?。。?/p>

加了全局鎖，就意味著整個數(shù)據(jù)庫在備份期間都是只讀狀態(tài)，那么在數(shù)據(jù)庫備份期間，業(yè)務就只能停擺了。

所以這種方式也不是最佳方案。

3. 事務

不知道小伙伴們是否還記得松哥之前和大家分享的數(shù)據(jù)庫的隔離級別，四種隔離級別中有一個是 可重復讀（REPEATABLE READ） ，這也是 MySQL 默認的隔離級別。

在這個隔離級別下，如果用戶在另外一個事務中執(zhí)行同條 SELECT 語句數(shù)次，結果總是相同的。（因為正在執(zhí)行的事務所產生的數(shù)據(jù)變化不能被外部看到）。

換言之，在 InnoDB 這種支持事務的存儲引擎中，那么我們就可以在備份數(shù)據(jù)庫之前先開啟事務，此時會先創(chuàng)建一致性視圖，然后整個事務執(zhí)行期間都在用這個一致性視圖，而且由于 MVCC 的支持，備份期間業(yè)務依然可以對數(shù)據(jù)進行更新操作，并且這些更新操作不會被當前事務看到。

在可重復讀的隔離級別下，即使其他事務更新了表數(shù)據(jù)，也不會影響備份數(shù)據(jù)庫的事務讀取結果，這就是事務四大特性中的隔離性，這樣備份期間備份的數(shù)據(jù)一直是在開啟事務時的數(shù)據(jù)。

具體操作也很簡單，使用 mysqldump 備份數(shù)據(jù)庫的時候，加上 -–single-transaction 參數(shù)即可。

為了看到 -–single-transaction 參數(shù)的作用，我們可以先開啟 general_log ， general_log 即 General Query Log，它記錄了 MySQL 服務器的操作。當客戶端連接、斷開連接、接收到客戶端的 SQL 語句時，會向 general_log 中寫入日志，開啟 general_log 會損失一定的性能，但是在開發(fā)、測試環(huán)境下開啟日志，可以幫忙我們加快排查出現(xiàn)的問題。

通過如下查詢我們可以看到，默認情況下 general_log 并沒有開啟：

我們可以通過修改配置文件 my.cnf(Linux)/my.ini（Windows） ，在 mysqld 下面增加或修改（如已存在配置項） general_log 的值為1，修改后重啟 MySQL 服務即可生效。

也可以通過在 MySQL 終端執(zhí)行 set global general_log = ON 來開啟 general log ，此方法可以不用重啟 MySQL 。

開啟之后，默認日志的目錄是 mysql 的 data 目錄，文件名默認為 主機名.log 。

接下來，我們先來執(zhí)行一個不帶 -–single-transaction 參數(shù)的備份，如下：

mysqldump -h localhost -uroot -p123 test08 > test08.sql

大家注意默認的 general_log 的位置。

接下來我們再來加上 -–single-transaction 參數(shù)看看：

mysqldump -h localhost -uroot -p123 --single-transaction test08 > test08.sql

大家看我藍色選中的部分，可以看到，確實先開啟了事務，然后才開始備份的，對比不加 -–single-transaction 參數(shù)的日志，多了開啟事務這一部分。

4. 小結

總結一下，加事務備份似乎是一個不錯的選擇，不過這個方案也有一個局限性，那就是只適用于支持事務的引擎如 InnoDB，對于 MyISAM 這樣的存儲引擎，如果要備份，還是乖乖的使用全局鎖吧。