事件背景

MySQL資料庫每日零點自動全備
某天上午9點，二狗子不小心drop了一個數據庫
我們需要通過全備的資料檔案，以及增量的binlog檔案進行資料恢復

主要思想與原理

利用全備的sql檔案中記錄的CHANGE MASTER語句，binlog檔案及其位置點資訊，找出binlog檔案增量的部分
用mysqlbinlog命令將上述的binlog檔案匯出為sql檔案，並剔除其中的drop語句
通過全備檔案和增量binlog檔案的匯出sql檔案，就可以恢復到完整的資料

過程示意圖

操作過程

模擬資料

CREATE TABLE `student` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` char(20) NOT NULL,
  `age` tinyint(2) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 
 
mysql> insert student values(1,'zhangsan',20); 
mysql> insert student values(2,'lisi',21); 
mysql> insert student values(3,'wangwu',22);

全備命令

# mysqldump -uroot -p -B -F -R -x --master-data=2 test|gzip >/server/backup/test_$(date +%F).sql.gz

引數說明：

    -B 指定資料庫
    -F 重新整理日誌
    -R 備份儲存過程等
    -x 鎖表
    --master-data 在備份語句裡新增CHANGE MASTER語句以及binlog檔案及位置點資訊

繼續插入資料並刪庫

mysql> insert student values(4,'xiaoming',20);
mysql> insert student values(5,'xiaohong',20); 

在插入資料的時候我們模擬誤操作，刪除test資料庫。

mysql> drop database test;

此時，全備之後到誤操作時刻之間，使用者寫入的資料在binlog中，需要恢復出來。
檢視全備之後新增的binlog檔案

# cd /server/backup/
# ls
test_2020-08-19.sql.gz
# gzip -d test_2020-08-19.sql.gz 
# grep CHANGE test_2020-08-19.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;

這是全備時刻的binlog檔案位置，即mysql-bin.000003的107行，因此在該檔案之前的binlog檔案中的資料都已經包含在這個全備的sql檔案中了
移動binlog檔案，並讀取sql，剔除其中的drop語句

# cp /data/3306/mysql-bin.000003 /server/backup/
# mysqlbinlog -d test mysql-bin.000003 >mysql-bin.000003.sql

接下來，使用vim編輯mysql-bin.000003.sql檔案，剔除drop語句

注意：在恢復全備資料之前必須將該binlog檔案移出，否則恢復過程中，會繼續寫入語句到binlog，最終導致增量恢復資料部分變得比較混亂
恢復資料

# mysql -uroot -p < test_2020-08-19.sql 
# mysql -uroot -p -e "select * from test.student;"
+----+----------+-----+
| id | name     | age |
+----+----------+-----+
|  1 | zhangsan |  20 |
|  2 | lisi     |  21 |
|  3 | wangwu   |  22 |
+----+----------+-----+

此時恢復了全備時刻的資料，然後使用mysql-bin.000003.sql檔案恢復全備時刻到刪除資料庫之間，新增的資料。

# mysql -uroot -p test < mysql-bin.000003.sql 
# mysql -uroot -p -e "select * from test.student;"
+----+----------+-----+
| id | name     | age |
+----+----------+-----+
|  1 | zhangsan |  20 |
|  2 | lisi     |  20 |
|  3 | wangwu   |  20 |
|  4 | xiaoming |  20 | 
|  5 | xiaohong |  20 |
+----+----------+-----+

此時，整個恢復過程結束，是不是很簡單呢？沒錯，就是這麼簡單！！

# 總結

    適合人為SQL語句造成的誤操作或者沒有主從複製等的熱備情況宕機時的修復。
    恢復條件要全備和增量的所有資料。
    恢復時建議對外停止更新，即禁止更新資料庫。
    先恢復全量，然後把全備時刻點以後的增量日誌，按順序恢復成SQL檔案，然後把檔案中有問題的SQL語句刪除（也可通過時間和位置點），再恢復到資料庫。