寫在前面
估計二狗子這幾天是大姨夫來了,心情很鬱悶,情緒也很低落,工作的時候也有點心不在焉。讓他發個版本,結果,一行命令下去把線上的資料庫刪了!你沒聽錯:是刪掉了線上的資料庫!運營那邊頓時炸了鍋:怎麼回事?系統不能訪問了!什麼情況啊?!很多客戶都在投訴了!!
儘管運營那邊慌慌張張的不知所措,但是,我們作為技術人員還是要淡定,不就是刪了資料庫嗎?沒事,哥幫你搞定!
如果文章對你有點幫助,請微信搜尋並關注 冰河技術 微信公眾號,點贊、在看、留言和轉發,你的支援是我持續創作的最大動力!!
事件背景
- 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語句刪除(也可通過時間和位置點),再恢復到資料庫。
重磅福利
關注「 冰河技術 」微信公眾號,後臺回覆 “設計模式” 關鍵字領取《深入淺出Java 23種設計模式》PDF文件。回覆“Java8”關鍵字領取《Java8新特性教程》PDF文件。回覆“限流”關鍵字獲取《億級流量下的分散式限流解決方案》PDF文件,三本PDF均是由冰河原創並整理的超硬核教程,面試必備!!
好了,今天就聊到這兒吧!別忘了點個贊,給個在看和轉發,讓更多的人看到,一起學習,一起進步!!
寫在最後
如果你覺得冰河寫的還不錯,請微信搜尋並關注「 冰河技術 」微信公眾號,跟冰河學習高併發、分散式、微服務、大資料、網際網路和雲原生技術,「 冰河技術 」微信公眾號更新了大量技術專題,每一篇技術文章乾貨滿滿!不少讀者已經通過閱讀「 冰河技術 」微信公眾號文章,吊打面試官,成功跳槽到大廠;也有不少讀者實現了技術上的飛躍,成為公司的技術骨幹!如果你也想像他們一樣提升自己的能力,實現技術能力的飛躍,進大廠,升職加薪,那就關注「 冰河技術 」微信公眾號吧,每天更新超硬核技術乾貨,讓你對如何提升技術能力不再迷茫!