MySQL 閃回原理與實戰
DBA或開發人員,有時會誤刪或者誤更新資料,如果是線上環境並且影響較大,就需要能快速回滾。傳統恢復方法是利用備份重搭例項,再應用去除錯誤sql後的binlog來恢復資料。此法費時費力,甚至需要停機維護,並不適合快速回滾。也有團隊利用LVM快照來縮短恢復時間,但快照的缺點是會影響mysql的效能。
MySQL閃回(flashback)利用binlog直接進行回滾,能快速恢復且不用停機。本文將介紹閃回原理,給出筆者的實戰經驗,並對現存的閃回工具作比較。
開胃菜
某天,小明因種種原因,誤刪了大批線上使用者表的資料。他急忙找到公司DBA請求幫助,“客服電話已被打爆,大量使用者投訴無法登陸,領導非常惱火。請問多久能恢復資料?”DBA一臉懵逼,沉默十秒後,伸出一根手指。“你的意思是一分鐘就能恢復?太好了。”小明終於有些放鬆,露出了一絲笑容。“不,我們中有個人將會離開公司。”DBA沉痛的說道。
勿讓悲劇發生,儘早將此文轉給公司DBA。
閃回原理
binlog概述
MySQL binlog以event的形式,記錄了MySQL server從啟用binlog以來所有的變更資訊,能夠幫助重現這之間的所有變化。MySQL引入binlog主要有兩個目的:一是為了主從複製;二是某些備份還原操作後需要重新應用binlog。
有三種可選的binlog格式,各有優缺點:
-
statement:基於SQL語句的模式,binlog資料量小,但是某些語句和函式在複製過程可能導致資料不一致甚至出錯;
-
row:基於行的模式,記錄的是行的完整變化。很安全,但是binlog會比其他兩種模式大很多;
-
mixed:混合模式,根據語句來選用是statement還是row模式;
利用binlog閃回,需要將binlog格式設定為row。row模式下,一條使用innodb的insert會產生如下格式的binlog:
# at 1129
#161225 23:15:38 server id 3773306082 end_log_pos 1197 Query thread_id=1903021 exec_time=0 error_code=0
SET TIMESTAMP=1482678938/*!*/;
BEGIN
/*!*/;
# at 1197
#161225 23:15:38 server id 3773306082 end_log_pos 1245 Table_map: `test`.`user` mapped to number 290
# at 1245
#161225 23:15:38 server id 3773306082 end_log_pos 1352 Write_rows: table id 290 flags: STMT_END_F
BINLOG '
muJfWBPiFOjgMAAAAN0EAAAAACIBAAAAAAEABHRlc3QABHVzZXIAAwMPEQMeAAAC
muJfWB7iFOjgawAAAEgFAAAAACIBAAAAAAEAAgAD//gBAAAABuWwj+i1tVhK1hH4AgAAAAblsI/p
krFYStYg+AMAAAAG5bCP5a2ZWE/onPgEAAAABuWwj+adjlhNeAD4BQAAAAJ0dFhRYJM=
'/*!*/;
# at 1352
#161225 23:15:38 server id 3773306082 end_log_pos 1379 Xid = 5327954
COMMIT/*!*/;
閃回原理
既然binlog以event形式記錄了所有的變更資訊,那麼我們把需要回滾的event,從後往前回滾回去即可。
對於單個event的回滾,我們以表test.user來演示原理
mysql> show create table test.user\G
*************************** 1. row ***************************
Table: user
Create Table: CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8
對於delete操作,我們從binlog提取出delete資訊,生成的回滾語句是insert。(注:為了方便解釋,我們用binlog2sql將原始binlog轉化成了可讀SQL)
原始:DELETE FROM `test`.`user` WHERE `id`=1 AND `name`='小趙';
回滾:INSERT INTO `test`.`user`(`id`, `name`) VALUES (1, '小趙');
對於insert操作,回滾SQL是delete。
原始:INSERT INTO `test`.`user`(`id`, `name`) VALUES (2, '小錢');
回滾:DELETE FROM `test`.`user` WHERE `id`=2 AND `name`='小錢';
對於update操作,回滾sql應該交換SET和WHERE的值。
原始:UPDATE `test`.`user` SET `id`=3, `name`='小李' WHERE `id`=3 AND `name`='小孫';
回滾:UPDATE `test`.`user` SET `id`=3, `name`='小孫' WHERE `id`=3 AND `name`='小李';
閃回實戰
真實的閃回場景中,最關鍵的是能快速篩選出真正需要回滾的SQL。
我們使用開源工具binlog2sql來進行實戰演練。binlog2sql由美團點評DBA團隊(上海)出品,多次在線上環境做快速回滾。
首先我們安裝binlog2sql:
shell> git clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sql
shell> pip install -r requirments.txt
背景:小明在11:44時誤刪了test庫user表大批的資料,需要緊急回滾。
test庫user表原有資料
mysql> select * from user;
+----+--------+---------------------+
| id | name | addtime |
+----+--------+---------------------+
| 1 | 小趙 | 2013-11-11 00:04:33 |
| 2 | 小錢 | 2014-11-11 00:04:48 |
| 3 | 小孫 | 2016-11-11 20:25:00 |
| 4 | 小李 | 2013-11-11 00:00:00 |
.........
+----+--------+---------------------+
16384 rows in set (0.04 sec)
11:44時,user表大批資料被誤刪除。與此同時,正常業務資料是在繼續寫入的
mysql> delete from user where addtime>'2014-01-01';
Query OK, 16128 rows affected (0.18 sec)
mysql> select count(*) from user;
+----------+
| count(*) |
+----------+
| 261 |
+----------+
恢復資料步驟:
登入mysql,檢視目前的binlog檔案
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000053 | 168652863 |
| mysql-bin.000054 | 504549 |
+------------------+-----------+
最新的binlog檔案是mysql-bin.000054。我們的目標是篩選出需要回滾的SQL,由於誤操作人只知道大致的誤操作時間,我們首先根據時間做一次過濾。只需要解析test庫user表。(注:如果有多個sql誤操作,則生成的binlog可能分佈在多個檔案,需解析多個檔案)
shell> python binlog2sql/binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p'admin' -dtest -tuser --start-file='mysql-bin.000054'--start-datetime='2016-12-26 11:44:00' --stop-datetime='2016-12-26 11:50:00' > /tmp/raw.sql
raw.sql 輸出:
DELETE FROM `test`.`user` WHERE `addtime`='2014-11-11 00:04:48' AND `id`=2 AND `name`='小錢' LIMIT 1; #start 257427 end 265754 time 2016-12-26 11:44:56
DELETE FROM `test`.`user` WHERE `addtime`='2015-11-11 20:25:00' AND `id`=3 AND `name`='小孫' LIMIT 1; #start 257427 end 265754 time 2016-12-26 11:44:56
...
DELETE FROM `test`.`user` WHERE `addtime`='2016-12-14 23:09:07' AND `id`=24530 AND `name`='tt' LIMIT 1; #start 257427 end 504272 time 2016-12-26 11:44:56
INSERT INTO `test`.`user`(`addtime`, `id`, `name`) VALUES ('2016-12-10 00:04:33', 32722, '小王'); #start 504299 end 504522 time 2016-12-26 11:49:42
...
/*
注意:假如執行的時候報錯:
Traceback (most recent call last): File "binlog2sql/binlog2sql.py", line 125, in <module> binlog2sql.process_binlog() File "binlog2sql/binlog2sql.py", line 70, in process_binlog for binlogevent in stream: File "/usr/lib/python2.6/site-packages/pymysqlreplication/binlogstream.py", line 370, in fetchone pkt = self._stream_connection._read_packet() File "/usr/lib/python2.6/site-packages/pymysql/connections.py", line 983, in _read_packet packet.check_error() File "/usr/lib/python2.6/site-packages/pymysql/connections.py", line 395, in check_error err.raise_mysql_exception(self._data) File "/usr/lib/python2.6/site-packages/pymysql/err.py", line 107, in raise_mysql_exception raise errorclass(errno, errval) pymysql.err.InternalError: (1236, u'Misconfigured master - server id was not set')
可以通過set global server_id=N;然後再次執行該語句即可。
*/
根據位置資訊,我們確定了誤操作sql來自同一個事務,準確位置在257427-504272之間(binlog2sql對於同一個事務會輸出同樣的start position)。再根據位置過濾,使用 -B 選項生成回滾sql,檢查回滾sql是否正確。(注:真實場景下,生成的回滾SQL經常會需要進一步篩選。結合grep、編輯器等)
shell> python binlog2sql/binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p'admin' -dtest -tuser --start-file='mysql-bin.000054'--start-position=257427 --stop-position=504272 -B > /tmp/rollback.sql
rollback.sql 輸出:
INSERT INTO `test`.`user`(`addtime`, `id`, `name`) VALUES ('2016-12-14 23:09:07', 24530, 'tt'); #start 257427 end 504272 time 2016-12-26 11:44:56
INSERT INTO `test`.`user`(`addtime`, `id`, `name`) VALUES ('2016-12-12 00:00:00', 24529, '小李'); #start 257427 end 504272 time 2016-12-26 11:44:56
...
INSERT INTO `test`.`user`(`addtime`, `id`, `name`) VALUES ('2014-11-11 00:04:48', 2, '小錢'); #start 257427 end 265754 time 2016-12-26 11:44:56
shell> wc -l /tmp/rollback.sql
16128 /tmp/rollback.sql
與業務方確認回滾sql沒問題,執行回滾語句。登入mysql,確認回滾成功。
shell> mysql -h127.0.0.1 -P3306 -uadmin -p'admin' < /tmp/rollback.sql
mysql> select count(*) from user;
+----------+
| count(*) |
+----------+
| 16389 |
+----------+
TIPS
-
閃回的關鍵是快速篩選出真正需要回滾的SQL。
-
先根據庫、表、時間做一次過濾,再根據位置做更準確的過濾。
-
由於資料一直在寫入,要確保回滾sql中不包含其他資料。可根據是否是同一事務、誤操作行數、欄位值的特徵等等來幫助判斷。
-
執行回滾sql時如有報錯,需要查實具體原因,一般是因為對應的資料已發生變化。由於是嚴格的行模式,只要有唯一鍵(包括主鍵)存在,就只會報某條資料不存在的錯,不必擔心會更新不該操作的資料。
-
如果待回滾的表與其他表有關聯,要與開發說明回滾和不回滾各自的副作用,再確定方案。
-
回滾後資料變化,可能對使用者和線上應用造成困惑(類似幻讀)。
再重複下最重要的兩點:篩選出正確SQL!溝通清楚!
閃回工具
MySQL閃回特性最早由阿里彭立勳開發,彭在2012年給官方提交了一個patch,並對閃回設計思路做了說明(設計思路很有啟發性,強烈推薦閱讀)。但是因為種種原因,業內安裝這個patch的團隊至今還是少數,真正應用到線上的更是少之又少。彭之後,又有多位人員針對不同mysql版本不同語言開發了閃回工具,原理用的都是彭的思路。
我將這些閃回工具按實現方式分成了三類。
第一類是以patch形式整合到官方工具mysqlbinlog中。以彭提交的patch為代表。
優點
上手成本低。mysqlbinlog原有的選項都能直接利用,只是多加了一個閃回選項。閃回特性未來有可能被官方收錄。
支援離線解析。
缺點
相容性差、專案活躍度不高。由於binlog格式的變動,如果閃回工具作者不及時對補丁升級,則閃回工具將無法使用。目前已有多位人員分別針對mysql5.5,5.6,5.7開發了patch,部分專案程式碼公開,但總體上活躍度都不高。
難以新增新功能,實戰效果欠佳。在實戰中,經常會遇到現有patch不滿足需求的情況,比如要加個表過濾,很簡單的一個需求,程式碼改動也不會大,但對大部分DBA來說,改mysql原始碼還是很困難的事。
安裝稍顯麻煩。需要對mysql原始碼打補丁再編譯生成。
這些缺點,可能都是閃回沒有流行開來的原因。
第二類是獨立工具,通過偽裝成slave拉取binlog來進行處理。以binlog2sql為代表。
優點
相容性好。偽裝成slave拉binlog這項技術在業界應用的非常廣泛,多個開發語言都有這樣的活躍專案,MySQL版本的相容性由這些專案搞定,閃回工具的相容問題不再突出。
新增新功能的難度小。更容易被改造成DBA自己喜歡的形式。更適合實戰。
安裝和使用簡單。
缺點
必須開啟MySQL server。
第三類是簡單指令碼。先用mysqlbinlog解析出文字格式的binlog,再根據回滾原理用正則進行匹配並替換。
優點
指令碼寫起來方便,往往能快速搞定某個特定問題。
安裝和使用簡單。
支援離線解析。
缺點
通用性不好。
可靠性不好。
就目前的閃回工具而言,線上環境的閃回,筆者建議使用binlog2sql,離線解析使用mysqlbinlog。
關於DDL的flashback
本文所述的flashback僅針對DML語句的快速回滾。但如果誤操作是DDL的話,是無法利用binlog做快速回滾的,因為即使在row模式下,binlog對於DDL操作也不會記錄每行資料的變化。要實現DDL快速回滾,必須修改MySQL原始碼,使得在執行DDL前先備份老資料。目前有多個mysql定製版本實現了DDL閃回特性,阿里林曉斌團隊提交了patch給MySQL官方,MariaDB預計在不久後加入包含DDL的flashback特性。DDL閃回的副作用是會增加額外儲存。考慮到其應用頻次實在過低,本文不做詳述,有興趣的同學可以自己去了解,重要的幾篇文章我在參考資料中做了引用。
有任何問題,或有mysql閃回相關的優秀工具優秀文章遺漏,煩請告知。 [email protected]
參考資料
[1] MySQL Internals Manual , Chapter 20 The Binary Log
[2] 彭立勳,MySQL下實現閃回的設計思路
[3] Lixun Peng, Provide the flashback feature by binlog
[4] 王廣友,mysqlbinlog flashback 5.6完全使用手冊與原理
[5] 姜承堯, 拿走不謝,Flashback for MySQL 5.7
[6] 林曉斌, MySQL閃回方案討論及實現
[7] xiaobin lin, flashback from binlog for MySQL
[8] mariadb.com, AliSQL and some features that have made it into MariaDB Server
[9] danfengcao, binlog2sql: Parse MySQL binlog to SQL you want
--注意:需要保證所在環境已安裝python,且python能正常訪問資料庫(已安裝MySQL connector)
--------------------- 本文來自 雅冰石 的CSDN 部落格 ,全文地址請點選:https://blog.csdn.net/yabingshi_tech/article/details/54313459?utm_source=copy