[[210534]]

由于運(yùn)維、DBA的誤操作或是業(yè)務(wù)bug，我們?cè)诓僮髦袝r(shí)不時(shí)會(huì)出現(xiàn)誤刪除數(shù)據(jù)情況。早期要想恢復(fù)數(shù)據(jù)，只能讓業(yè)務(wù)人員根據(jù)線上操作日志，構(gòu)造誤刪除的數(shù)據(jù)，或者DBA使用binlog和備份的方式恢復(fù)數(shù)據(jù)，不管那種，都非常費(fèi)時(shí)費(fèi)力，而且容易出錯(cuò)。直到彭立勛***在MySQL社區(qū)為mysqlbinlog擴(kuò)展了閃回功能。

在美團(tuán)點(diǎn)評(píng)，我們也遇到過研發(fā)人員誤刪主站的配置信息，從而導(dǎo)致主站長達(dá)2個(gè)小時(shí)不可用的情況。DBA同學(xué)當(dāng)時(shí)使用了技術(shù)團(tuán)隊(duì)自研的binlog2sql完成了數(shù)據(jù)恢復(fù)，并多次挽救了線上誤刪數(shù)據(jù)導(dǎo)致的嚴(yán)重故障。不過，binlog2sql在恢復(fù)速度上不盡如人意，因此我們開發(fā)了一個(gè)新的工具——MyFlash，它很好地解決了上述痛點(diǎn)，能夠方便并且高效地進(jìn)行數(shù)據(jù)恢復(fù)。

現(xiàn)在該工具正式開源，開源地址為：https://github.com/Meituan-Dianping/MyFlash 。

閃回工具現(xiàn)狀

先來看下目前市面上已有的恢復(fù)工具，我們從實(shí)現(xiàn)角度把它們劃分成如下幾類。

mysqlbinlog工具配合sed、awk。該方式先將binlog解析成類SQL的文本，然后使用sed、awk把類SQL文本轉(zhuǎn)換成真正的SQL。

•     優(yōu)點(diǎn)：當(dāng)SQL中字段類型比較簡單時(shí)，可以快速生成需要的SQL，且編程門檻也比較低。
•     缺點(diǎn)：當(dāng)SQL中字段類型比較復(fù)雜時(shí)，尤其是字段中的文本包含HTML代碼，用awk、sed等工具時(shí)，就需要考慮極其復(fù)雜的轉(zhuǎn)義等情況，出錯(cuò)概率很大。

給數(shù)據(jù)庫源碼打patch。該方式擴(kuò)展了mysqlbinlog的功能，增加Flashback選項(xiàng)。

•     優(yōu)點(diǎn)：復(fù)用了MySQL Server層中binlog解析等代碼，一旦穩(wěn)定之后，無須關(guān)心復(fù)雜的字段類型，且效率較高。
•     缺點(diǎn)：在修改前，需要對(duì)MySQL的復(fù)制代碼結(jié)構(gòu)和細(xì)節(jié)需要較深的了解。版本比較敏感，在MySQL 5.6上做的patch，基本不能用于MySQL 5.7的回滾操作。升級(jí)困難，因?yàn)閜atch的代碼是分布在MySQL的各個(gè)文件和函數(shù)中，一旦MySQL代碼改變，特別是復(fù)制層的重構(gòu)，升級(jí)的難度不亞于完全重新寫一個(gè)。

使用業(yè)界提供的解析binlog的庫，然后進(jìn)行SQL構(gòu)造，其優(yōu)秀代表是binlog2sql。

•     優(yōu)點(diǎn)：使用業(yè)界成熟的庫，因此穩(wěn)定性較好，且上手難度較低。
•     缺點(diǎn)：效率往往較低，且實(shí)現(xiàn)上受制于binlog庫提供的功能。

上述幾種實(shí)現(xiàn)方式，主要是提供的過濾選項(xiàng)較少，比如不能提供基于SQL類型的過濾，需要回滾一個(gè)delete語句，導(dǎo)致在回滾時(shí)，需要結(jié)合awk、sed等工具進(jìn)行篩選。

總結(jié)了上述幾種工具的優(yōu)缺點(diǎn)，我認(rèn)為理想的閃回工具需要有以下特性。

a. 無需把binlog解析成文本，再進(jìn)行轉(zhuǎn)換。

b. 提供原生的基于庫、表、SQL類型、位置、時(shí)間等多種過濾方式。

c. 支持MySQL多個(gè)版本。

d. 對(duì)于數(shù)據(jù)庫的代碼重構(gòu)不敏感，利于升級(jí)。

e. 自主掌控binlog解析，提供盡可能靈活的方式。

在這些特性中，binlog的解析是一切工作的基礎(chǔ)。接下來我會(huì)介紹binlog的基本結(jié)構(gòu)。

binlog格式初探

binlog格式概覽

一個(gè)完整的binlog文件是由一個(gè)format description event開頭，一個(gè)rotate event結(jié)尾，中間由多個(gè)其他event組合而成。

binlog文件實(shí)例：

每個(gè)event都是由event header 和event data組成。下面簡單介紹下幾種常見的binlog event。

① formart description event

表達(dá)的含義是：

170905  01:59:33 server id 10  end_log_pos 123 CRC32 0xed1ec563 

Start: binlog v 4, server v 5.7.18-log created 170905  01:59:33

② table map event

表達(dá)的含義是：

    170905  01:59:33 server id 10  end_log_pos 339 CRC32 0x3de40c0d     

    Table_map: `test`.`test4` mapped to number 238

③ update row event

表達(dá)的含義是：

    170905  01:59:33 server id 10  end_log_pos 385 CRC32 0x179ef6dd     

    Update_rows: table id 238 flags: STMT_END_F 

    UPDATE `test`.`test4` WHERE @1=3 SET @1=13;

binlog event回滾

根據(jù)上面的binlog介紹，可以看到每個(gè)binlog event中event header有個(gè)type_code，其中insert為30，update為31，delete為32。對(duì)于insert和delete兩個(gè)相反的操作，只需把type_code互換，則在binlog event級(jí)別完成回滾。

而對(duì)于update操作，其格式如下。

其中，BI是指before image，AI是指after image。

我們只需依次遍歷修改前的數(shù)據(jù)和修改后的數(shù)據(jù)，并一一互換即可。因此整個(gè)回滾操作的難點(diǎn)在于回滾update語句，而update語句回滾的核心在于計(jì)算出每個(gè)AI、BI的長度。下面介紹下長度以及部分字段的計(jì)算方法。

鏡像長度計(jì)算

鏡像是由一個(gè)個(gè)字段組成的，根據(jù)字段類型的不同，其計(jì)算長度的方法也不一樣。

• 只與字段類型相關(guān)。比如int占用4個(gè)字節(jié)，bingint占用8個(gè)字節(jié)。其中類型信息可以從table map event中獲取。
• 與字段類型及其參數(shù)相關(guān)。比如decimal（18，9），占用9個(gè)字節(jié)，參數(shù)信息在table map event中。
• 與字段類型、參數(shù)以及實(shí)際存儲(chǔ)的值相關(guān)。比如varchar（10），有1個(gè)字節(jié)表示長度，之后的字節(jié)才表示真正的數(shù)據(jù)。比如varchar（280），有2個(gè)字節(jié)表示長度。實(shí)際的長度和數(shù)據(jù)在一起。

解析binlog中的若干個(gè)關(guān)鍵點(diǎn)

① length encoded integer

binlog中一個(gè)或者多個(gè)字節(jié)組合，分別表示了不同的含義。比如，timestamp是由固定的4個(gè)字節(jié)組成，event類型由一個(gè)字節(jié)表示；數(shù)據(jù)庫名和表名最長為64個(gè)字符，即使每個(gè)字符占用3個(gè)字節(jié)，那么占用的字節(jié)數(shù)為192<255。因此最多使用一個(gè)字節(jié)，就可以完成實(shí)際長度表示。

然而列的實(shí)際數(shù)量，可能需要超過1個(gè)字節(jié)、2個(gè)字節(jié)、3個(gè)字節(jié)甚至8個(gè)字節(jié)去表示。如果我們使用***的8個(gè)字節(jié)去表示，那么在絕大多數(shù)情況下都是浪費(fèi)存儲(chǔ)空間的。針對(duì)這種情況，length encoded integer應(yīng)運(yùn)而生。

比如在獲取一個(gè)varchar類型的長度時(shí)，首先讀取***個(gè)字節(jié)，如果值小于251，那么varchar的長度就是***個(gè)字節(jié)表示的長度。如果***個(gè)字節(jié)的值為0xFC，那么varchar的長度是由該字節(jié)之后的后兩個(gè)字節(jié)組成，以此類推。

② decimal類型

decimal是由整數(shù)部分和小數(shù)部分組成。無論是整數(shù)還是小數(shù)，每9個(gè)數(shù)字，需要4個(gè)字節(jié)。如果不是9的倍數(shù)，剩余的小數(shù)位，需要的字節(jié)數(shù)如下，為方便描述，將該關(guān)系定義為函數(shù)Fnum。

舉例，對(duì)于 decimal（18,10）：

• 整數(shù)部分可展示的為8，用int，即4個(gè)字節(jié)。
• 小數(shù)部分，需要的字節(jié)數(shù)為 (10 /9)*4+Fnum(10%9)=5。
• 那么總共加起來需要4+5=9個(gè)字節(jié)。

閃回工具架構(gòu)

在上面的章節(jié)中，介紹了單個(gè)binlog event的反轉(zhuǎn)方法。在實(shí)踐中，我們往往需要把某個(gè)binlog，按照指定的條件，過濾出需要的binlog，并進(jìn)行反轉(zhuǎn)。那么MyFlash是如何完成這些目標(biāo)的呢？

解析binlog

首先把binlog文件，解析成多個(gè)event，放入到相關(guān)隊(duì)列中。在實(shí)現(xiàn)上，為了盡可能加快解析速度，可以讓用戶指定解析的開始與結(jié)束位置。把binlog文件解析成binlog event后，再判斷下是否符合指定的時(shí)間條件，若不符合，則丟棄該event。

注意：用戶可以不指定位置和時(shí)間，則解析整個(gè)文件。如果只指定時(shí)間，那么也需要從文件開始處解析，取出時(shí)間信息，再進(jìn)行判斷。因此，當(dāng)需要回滾的binlog只占整個(gè)binlog的一小部分時(shí)，推薦使用指定位置。

重組event

把binlog event組成最小執(zhí)行單元。在常見的binlog event中table_map event包含了所要了表名、庫名等元數(shù)據(jù)信息，而row_event(包含write_event、delete_event、update_event)包含了真正的數(shù)據(jù)。因此在設(shè)計(jì)中使用了一個(gè)最小執(zhí)行單元概念。所謂的最小執(zhí)行單元，即least execution event unit，通常包含一個(gè)table_map event和若干個(gè)row_event。

比如在binlog格式概覽一節(jié)中，介紹了table_map_event和update_row_event。如果只有update_row_event，那么我們無法知道這個(gè)event對(duì)應(yīng)的行記錄變更對(duì)應(yīng)的表。因此一個(gè)完整的最小執(zhí)行單元最少包含一個(gè)table_map_event和write_row_event、update_row_even、delete_row_event中的一個(gè)。

為什么我們需要使用最小執(zhí)行單元？因?yàn)槲覀冊(cè)陂W回操作時(shí)，不能簡單的把每個(gè)event反轉(zhuǎn)之后，然后再將所有event的順序反轉(zhuǎn)過來。如果這樣的話，就會(huì)出現(xiàn)table_map event在row event之后，這顯然是違反binlog執(zhí)行邏輯的。

有了最小執(zhí)行單元之后，只需兩步，即可完成反轉(zhuǎn)。

a. 反轉(zhuǎn)最小執(zhí)行單元中的row event。

b. 逆序最小執(zhí)行單元隊(duì)列，即可。

當(dāng)然在反轉(zhuǎn)前，也可以增加過濾操作。比如過濾庫名、表名和SQL類型等。

生成binlog文件

有了逆序的最小執(zhí)行單元隊(duì)列后，只需把每個(gè)最小執(zhí)行單元依次輸入到文件即可。不過不要忘了修改每個(gè)binlog event里的next_position，用來表示下一個(gè)binlog的位置。

性能對(duì)比

測試場景

使用testFlashback2，插入100萬條數(shù)據(jù)：

CREATE TABLE `testFlashback2` ( 
  `id` int(11) NOT NULL AUTO_INCREMENT, 
  `nameShort` varchar(20) DEFAULT NULL, 
  `nameLong` varchar(260) DEFAULT NULL, 
  `amount` decimal(19,9) DEFAULT NULL, 
  `amountFloat` float DEFAULT NULL, 
  `amountDouble` double DEFAULT NULL, 
  `createDatetime6` datetime(6) DEFAULT NULL, 
  `createDatetime` datetime DEFAULT NULL, 
  `createTimestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
  `nameText` text, 
  `nameBlob` blob, 
  `nameMedium` mediumtext, 
  PRIMARY KEY (`id`) 
) ENGINE=InnoDB 
 
mysql> select count(*) from testFlashback2; 
+----------+ 
| count(*) | 
+----------+ 
|  1048576 | 
+----------+ 
1 row in set (0.16 sec) 
 
delete from testFlashback2; 

測試結(jié)果

從上述圖表中可以看出，MyFlash的速度最快。