Oracle有一個(gè)閃回（flashback）功能，能夠用戶恢復(fù)誤操作的數(shù)據(jù)。本文討論MySQL中支持閃回的方案。

1、 閃回的目標(biāo)

即使為了數(shù)據(jù)安全，我們搭建了主從。但實(shí)時(shí)主從備份只能防止硬件問(wèn)題，比如主庫(kù)的硬盤損壞。但對(duì)于誤操作，則無(wú)能為力。比如在主庫(kù)誤刪一張表，或者一個(gè)update語(yǔ)句沒(méi)有指定where條件，導(dǎo)致全表被更新。當(dāng)操作被同步到從庫(kù)上后，則主從都“回天無(wú)力”。

線上或者測(cè)試環(huán)境經(jīng)常出現(xiàn)的誤操作總是讓DBA同學(xué)那么鬧心。

閃回的目的是要讓數(shù)據(jù)庫(kù)在commit之后，還能恢復(fù)到之前的某個(gè)狀態(tài)，整庫(kù)或指定的表。

這里我們討論用binlog來(lái)實(shí)現(xiàn)閃回的方案。

2、 無(wú)米無(wú)炊一

恢復(fù)到之前的某個(gè)狀態(tài)，是需要數(shù)據(jù)的。這數(shù)據(jù)可以是 a) 回滾步驟 或者 b) 操作之前的數(shù)據(jù)狀態(tài)原文。

但我們知道，若使用statement，并沒(méi)有上述需要的數(shù)據(jù)。試想binlog中記錄了一句update t set f1=3 where id=3。怎么恢復(fù)呢？

因此，我們的第一個(gè)“米”，就是binlog必須是row based的。在row base下，binlog同時(shí)記錄了更新前后的整行記錄。

a)單個(gè)語(yǔ)句的閃回

了row base的binlog后，我們來(lái)分析一下怎么實(shí)現(xiàn)閃回。平時(shí)的DML無(wú)非三種操作，增刪改，先說(shuō)三種操作的日志格式。

一個(gè)語(yǔ)句分成兩個(gè)event (實(shí)際上不止，其他可以忽略)， 一個(gè)table_map event 和 一個(gè)Rows_log_event。Table_map event是一樣的，主要看Rows_log_event。

每個(gè)Rows_log_event中包含event_type, 可選值為WRITE_ROWS_EVENT、UPDATE_ROWS_EVENT、DELETE_ROWS_EVENT。從宏名字就能看出用途。

對(duì)于insert和delete，event中包含了插入/刪除的記錄的所有字段的值(太爽了。。)

對(duì)于update操作，event中依次記錄舊行， 新行的值。

因此我們看到，這些信息足夠讓我們對(duì)單個(gè)操作實(shí)現(xiàn)“逆操作”。

i. 對(duì)于insert操作，只需要把event_type改成DELETE_ROWS_EVENT；對(duì)于delete操作，改成WRITE_ROWS_EVENT

ii.  對(duì)于update操作，只需要把event中的舊行和新行值對(duì)調(diào)即可。

b)binlog的閃回

我們只需要把binlog文件反向執(zhí)行，每個(gè)操作都執(zhí)行逆操作即可。當(dāng)然也不是所有的event都反轉(zhuǎn)。Table_map event必須還是在Rows_log_event每個(gè)操作之前。目前的方案是用mysqlbinlog工具，增加一個(gè)flashback參數(shù)，輸出結(jié)果為一個(gè)新的binlog文件――姑且叫做flashbacklog，這個(gè)flashbacklog順序執(zhí)行，可制定某張表和執(zhí)行到哪個(gè)pos，來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)的閃回。 

3、 無(wú)米無(wú)炊二

上面我們說(shuō)了DML的閃回方案。但對(duì)于DDL卻無(wú)能為力，對(duì)于大多數(shù)的ddl，即使是row base格式，binlog中仍只記錄語(yǔ)句本身。對(duì)于刪表操作，只記錄一個(gè)語(yǔ)句drop table t。僅憑這句話，無(wú)法還原表的數(shù)據(jù)。

雖然可以將一個(gè)drop table語(yǔ)句轉(zhuǎn)換成先delete再刪表，性能卻會(huì)降低很多。這里我們用上面說(shuō)道的另外一種可用數(shù)據(jù)：“操作前數(shù)據(jù)備份”。

按順序我們先討論怎么保存數(shù)據(jù)，再討論怎么閃回。

保存數(shù)據(jù)

先說(shuō)DDL的分類。有一類DDL，是不需要重建表的，比如加非聚簇索引。這類操作其實(shí)不會(huì)丟數(shù)據(jù)，也是在原表上直接操作，對(duì)于我們“以恢復(fù)數(shù)據(jù)為目的”的閃回，是可以先忽略的。 另外一類，則是會(huì)影響到表數(shù)據(jù)的操作。比如

a)  Drop/truncate table

這兩個(gè)操作直接把表數(shù)據(jù)清空。

b)   Alter table add、drop、change column

這類操作的執(zhí)行過(guò)程是，1) 按照新的表定義建立一個(gè)臨時(shí)表tmpa，2) 將原表數(shù)據(jù)拷貝到臨時(shí)表，3)將原始表改名tmpb，4)將tmpa改名為原表名，5)將tmpb刪除。

我們分析上面的兩個(gè)操作，都有一個(gè)“刪除數(shù)據(jù)”的過(guò)程。

因此我們的保存數(shù)據(jù)方法就是：在刪除的動(dòng)作開始之前，把表數(shù)據(jù)備份起來(lái)，然后留一個(gè)空表，在空表上執(zhí)行“刪除”操作。

用一個(gè)庫(kù) #bak_database存放這些歷史數(shù)據(jù)。

閃回

有了數(shù)據(jù)以后，我們就要想一個(gè)比較統(tǒng)一的方法來(lái)閃回。上面我們說(shuō)了對(duì)于DML操作，可以通過(guò)反向執(zhí)行所有逆操作來(lái)實(shí)現(xiàn)，對(duì)于語(yǔ)句里面的DDL，只能直接跳過(guò)。原因是一個(gè)DDL不一定有直接的逆操作。

因此我們的方案中要構(gòu)造這種逆操作。Event_type增加一種FLASHBACK_EVENT。這類操作形式與Query_Event相同，都是簡(jiǎn)單的SQL語(yǔ)句，只是包含了將數(shù)據(jù)恢復(fù)的操作。

舉例：

a)   對(duì)于altert table t add column 操作。

我們?cè)诓僮鞯倪^(guò)程中將臨時(shí)表tmpb，不刪除，而是保存到 #bak_database.#bak_table_xxxxx (后綴用于去重)，在我的patch中用當(dāng)前的時(shí)刻（微秒）。

對(duì)于這個(gè)語(yǔ)句，我們生成兩條FLASHBACK_EVENT，分別是 alter table `#bak_database`.`#bak_table_xxxxx` rename to `my_db`.`my_tbl`; 和 drop table  `my_db`.`my_tbl`;

這里的my_db和my_tbl分別為原來(lái)的庫(kù)名和表名。

所以mysqlbinlog工具怎么處理FLASHBACK_EVENT這類event呢，直接執(zhí)行就行了。（注意這兩個(gè)event也是反向執(zhí)行的，所以在恢復(fù)的時(shí)候是先刪除`my_db`.`my_tbl`，再?gòu)?bak_database恢復(fù)回來(lái)）

b)對(duì)于drop table操作

由于實(shí)際操作會(huì)把這個(gè)表刪，只需要一個(gè)alter table `#bak_database`.`#bak_table_xxxxx` rename to `my_db`.`my_tbl`; 即可。

4、 演示

初始狀態(tài)我們庫(kù)中只有一個(gè)表 test.tb，兩行

CREATE TABLE `tb` (
`c` int(11) NOT NULL DEFAULT '0′,
 `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`c`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;mysql> select * from tb;
+——+——+
| c    | d    |
+——+——+
|    1 |   10 |
|    2 |   20 |
+——+——+

模擬一個(gè)DML和一個(gè)DDL

insert into tb values(3,30);
alter table tb drop column d;  

這兩個(gè)操作后在binlog文件中生成的結(jié)果如下

說(shuō)明：

將mysqlbinloig中的其他信息去掉，其中紅色框中為insert語(yǔ)句產(chǎn)生的binlog，在flashback工具中會(huì)被轉(zhuǎn)化為delete操作。

兩個(gè)藍(lán)色框中的即為我們生成的FLASHBACK_EVENT。除了event_type與普通的query_event不同，還將庫(kù)名＋表名放在語(yǔ)句的前面，目的是為了flashback工具執(zhí)行按表閃回的時(shí)候可以直接識(shí)別表名，不需要解析binlog語(yǔ)句。

紫色框中就是那個(gè)真正的DDL操作，在flashback工具中被忽略。

所以上面的binlog被flashback工具解析后的結(jié)果是兩個(gè)DDL語(yǔ)句和一個(gè)delete操作，能夠恢復(fù)到表的初始狀態(tài)。

5、小結(jié)

這里討論了MySQL閃回的一種方案.

增加一種新的event_type, 不會(huì)影響原來(lái)mysqlbinlog工具的使用；

備份即將刪除的表，沒(méi)有增加額外的操作，不會(huì)對(duì)正常操作性能造成影響（當(dāng)然需要更多的存儲(chǔ)空間）。

實(shí)際上我們上面還留了一個(gè)“空擋”沒(méi)有討論，在方案完成后補(bǔ)充。

涉及到MySQL server本身和mysqlbinlog這個(gè)工具兩部分的修改，MySQL工具部分由@plinux同學(xué)實(shí)現(xiàn)。（其實(shí)如果不恢復(fù)DDL，可以只使用這個(gè)工具）.  server部分的改動(dòng)可以只部署slave，這樣slave同時(shí)擔(dān)負(fù)備份和閃回準(zhǔn)備的功能。

到此這篇關(guān)于MySQL中閃回功能的方案討論及實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)MySQL閃回內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論