本文轉載自微信公眾號「數倉寶貝庫」，作者李玥  。轉載本文請聯系數倉寶貝庫公眾號。

保證數據安全，最簡單且有效的方法就是定期備份數據，這樣無論因為出現何種問題而導致的數據損失，都可以通過備份來恢復數據。但是，如何備份才能最大程度地保證數據安全，并不是一件簡單的事情。

2018年曾出現過一次重大故障，某著名云服務商因為硬盤損壞，導致多個客戶數據全部丟失。通常來說，一個大的云服務商，數據通常都會有多個備份，即使硬盤損壞，也不會導致數據丟失的重大事故，但是因為各種各樣的原因，最終的結果是數據的三個副本都被刪除，數據丟失無法找回。

所以，并不是簡單地定期備份數據就可以高枕無憂了。下面就以最常用的MySQL為例來講解，如何更安全地實現數據的備份和恢復。

最簡單的備份方式就是全量備份。備份的時候，把所有的數據復制一份，存放到文件中，恢復的時候再把文件中的數據復制回去，這樣就可以保證恢復之后，數據庫中的數據與備份時的數據是完全一樣的。在MySQL中，我們可以使用mysqldump命令執行全量備份。

比如，全量備份數據庫test的命令如下：

1$mysqldump -uroot -p test > test.sql 

備份出來的文件是一個SQL文件，文件的內容就是創建數據庫、表，寫入數據等之類的SQL語句，如果要恢復數據，則直接執行這個備份的SQL文件就可以了：

$mysql -uroot test < test.sql 

不過，全量備份的代價非常高，為什么這么說呢?

首先，備份文件包含了數據庫中的所有數據，占用的磁盤空間非常大;其次，每次備份操作都要拷貝大量的數據，備份過程中會占用數據庫服務器大量的CPU和磁盤IO資源。同時，為了保證數據一致性，備份過程中很有可能會鎖表。這些都會導致在備份期間，數據庫本身的性能嚴重下降。所以，我們不能頻繁地對數據庫執行全量備份操作。

一般來說，在生產系統中，每天執行一次全量備份就已經是非常頻繁的了。這就意味著，如果數據庫中的數據丟失了，就只能恢復到最近一次全量備份的那個時間點，這個時間點之后的數據是無法找回的。也就是說，因為全量備份的代價比較高，不能頻繁地執行備份操作，所以全量備份不能做到完全無損的恢復。

既然全量備份代價太高，不能頻繁執行，那么有沒有代價較低的備份方法，能讓我們的數據少丟失甚至不丟失呢?增量備份可以達到這個目的。相比于全量備份，增量備份每次只用備份相對于上一次備份發生了變化的那部分數據，所以增量備份的速度更快。

MySQL自帶的Binlog，就是一種實時的增量備份工具。Binlog所記錄的就是MySQL數據變更的操作日志。開啟Binlog之后，MySQL中數據的每次更新操作，都會記錄到Binlog中。Binlog是可以回放的，回放Binlog，就相當于是把之前對數據庫中所有數據的更新操作，都按順序重新執行一遍，回放完成之后，數據自然就恢復了。這就是Binlog增量備份的基本原理。很多數據庫都有類似于MySQL Binlog的日志工具，原理也與Binlog相同，備份和恢復的方法也與之類似。

下面就來通過一個例子，講解如何使用Binlog進行備份和恢復。首先，使用“show variables like '%log_bin%'”命令確認一下是否開啟了Binlog功能：

 1mysql> show variables like '%log_bin%'; 
 2 
 3+---------------------------------+-----------------------------------+ 
 4 
 5| Variable_name                   | Value                             | 
 6 
 7+---------------------------------+-----------------------------------+ 
 8 
 9| log_bin                         | ON                                | 
10 
11| log_bin_basename                | /usr/local/var/mysql/binlog       | 
12 
13+---------------------------------+-----------------------------------+ 
14 
15mysql> show master status; 
16 
17+-------------+--------+------------+----------------+-----------------+ 
18 
19| File        |Position|Binlog_Do_DB|Binlog_Ignore_DB|Executed_Gtid_Set| 
20 
21+-------------+--------+------------+----------------+-----------------+ 
22 
23|binlog.000001|   18745|            |                 |                 | 
24 
25+-------------+--------+------------+----------------+-----------------+ 
26 

我們可以看到，當前這個數據庫已經開啟了Binlog，log_bin_basename表示Binlog文件在服務器磁盤上的具體位置。然后，我們用“show master status”命令查看當前Binlog的狀態，結果顯示了正在寫入的Binlog文件，以及其當前的位置。假設我們每天凌晨用mysqldump做一個全量備份，然后開啟Binlog，借助于這些備份操作，我們可以把數據恢復到全量備份之后的任意一個時刻。

下面就來做一個簡單的備份恢復演示。我們先模擬一次“刪庫跑路”的場景，直接把賬戶余額表清空：

1mysql> truncate table account_balance; 
2 
3Query OK, 0 rows affected (0.02 sec) 
4 
5mysql> select * from  account_balance; 
6 
7Empty set (0.00 sec) 
8 

然后進行數據恢復，首先執行一次全量恢復，把數據庫恢復到當天凌晨的狀態：

 1$mysql -uroot test < dump.sql 
 2 
 3mysql> select * from  account_balance; 
 4 
 5+---------+---------+---------------------+--------+ 
 6 
 7| user_id | balance | timestamp           | log_id | 
 8 
 9+---------+---------+---------------------+--------+ 
10 
11|       0 |     100 | 2020-02-13 20:24:33 |      3 | 
12 
13+---------+---------+---------------------+--------+ 

可以看到，表里面的數據已經恢復了，但還是比較舊的數據。接下來，我們再用Binlog把數據恢復到“刪庫跑路”之前的那個時刻：

 1$mysqlbinlog --start-datetime "2020-02-20 00:00:00" --stop-datetime "2020-02-20 15:09:00" /usr/local/var/mysql/binlog.000001 | mysql -uroot 
 2 
 3mysql> select * from  account_balance; 
 4 
 5+---------+---------+---------------------+--------+ 
 6 
 7| user_id | balance | timestamp           | log_id | 
 8 
 9+---------+---------+---------------------+--------+ 
10 
11|       0 |     200 | 2020-02-20 15:08:12 |      0 | 
12 
13+---------+---------+---------------------+--------+ 
14 

由恢復結果可以看出，數據已經恢復到當天的15點了。

通過定期的全量備份，配合Binlog，我們可以把數據恢復到任意一個時間點，再也不怕程序員“刪庫跑路”了。詳細的命令，可以參考MySQL官方文檔中的“備份和恢復”相關章節。

在執行備份和恢復的時候，大家需要特別注意如下兩個要點。

第一，也是最重要的，“不要把所有的雞蛋放在同一個籃子中”，無論是全量備份還是Binlog，都不要與數據庫存放在同一個服務器上。最好能存放到不同的機房，甚至不同城市，離得越遠越好。這樣即使出現機房著火、光纜被挖斷甚至地震也不怕數據丟失。

第二，在回放Binlog的時候，指定的起始時間可以比全量備份的時間稍微提前一點兒，這樣可以確保全量備份之后的所有操作都在恢復的Binlog范圍內，從而保證數據恢復的完整性。

因為回放Binlog的操作是具備冪等性的(為了確保回放的冪等性，需要將Binlog的格式設置為ROW格式)。

關于作者：李玥，美團基礎技術部高級技術專家，極客時間《后端存儲實戰課》《消息隊列高手課》等專欄作者。曾在當當網、京東零售等公司任職。從事互聯網電商行業基礎架構領域的架構設計和研發工作多年，曾多次參與雙十一和618電商大促。專注于分布式存儲、云原生架構下的服務治理、分布式消息和實時計算等技術領域，致力于推進基礎架構技術的創新與開源。

本文摘編自《電商存儲系統實戰：架構設計與海量數據處理》，經出版方授權發布。(ISBN：9787111697411)轉載請保留文章出處。