MySQL根據離線binlog快速「閃回」

昨天忽然有個客戶說誤操做，本身刪除了大量數據，CTO直接將我拉到一個討論組裏，說要幫他們恢復數據。他們本身挖的坑，打算讓開發那邊根據業務日誌去恢復，被告知只記錄的刪除主鍵這樣的信息，物理刪除，無能爲力。

上服務器看了下記錄的日誌，發現好幾臺上面都有被誤刪的記錄輸出。阿里RDS雖然能夠克隆一個恢復到刪除時間點前的實例，但這散落的幾萬個id找起來費力，還有就是幾個表之間關聯的數據也要恢復，以爲麻煩。

想到 MySQL 的閃回方案。之前看過好幾篇相關文章，甚至差點本身用python擼一個來解析binlog，反轉獲得回滾sql，實在沒空，這下要急用了。趕忙找了下網上「現成的方案」。

正文開始

---

MySQL（含阿里RDS）快速閃回能夠說是對數據庫誤操做的後悔藥，flashback功能能夠將數據庫返回到誤操做以前。可是即便oracle數據庫也只支持短期內的閃回。

網上現有開源的MySQL閃回實現，原理都是解析binlog，生成反向sql: (必須爲row模式)

1. 對於 delete 操做，生成insert （DELETE_ROWS_EVENT）

2. 對於 update 操做，交換binlog裏面值的順序 （UPDATE_ROWS_EVENT）

3. 對於 insert 操做，反向生成delete （WRITE_ROWS_EVENT）

4. 對於多個event，要逆向生成sql

開源實現：

• https://github.com/58daojia-d...

• https://github.com/danfengcao...

上面兩種實現方式，都是經過 python-mysql-replication 包，模擬出原庫的一個從庫，而後 show binary logs 來獲取binlog，發起同步binlog的請求，再解析EVENT。可是阿里雲 RDS 的binlog在同步給從庫以後， 很快就被 purge 掉了 。若是要恢復 昨天 的 部分數據 ，兩種方案都是拿不到binlog的。也就是閃回的時間有限。

還有一些比較簡單的實現，就是解析 binlog 物理文件，實現回滾，如 binlog-rollback.pl ，試過，可是速度太慢。

爲了避免影響速度，又想使用比較成熟的閃回方案，咱們能夠這樣作：

1. 藉助一個自建的 mysqld 實例，將已purge掉的binlog拷貝到該實例的目錄下

2. 在自建實例裏，提早建立好須要恢復的表（結構），由於工具須要鏈接上來從 information_schema.columns 獲取元數據信息

3. 拷貝的時候，能夠替換掉mysql實例本身的binlog文件名，保持連續

4. 可能要修改 mysql-bin.index，確保文件名還能被mysqld識別到

5. 重啓mysql實例，show binary logs 看一下是否在列表裏面

6. 接下來就可使用上面任何一種工具，模擬從庫，指定一個binlog文件，開始時間，結束時間，獲得回滾SQL

7. 再根據業務邏輯，篩選出須要的sql

<!--more-->
總之就是藉助另一個mysql，把binlog event傳輸過來。舒適提示：

1. 兩個實例間版本不要跨度太大

2. 注意文件權限

3. 若是原庫開啓了gtid，這個自建實例也要開啓gtid

示例：

python mysqlbinlog_back.py --host="localhost" --username="ecuser" --password="ecuser" --port=3306 \
--schema=dbname --tables="t_xx1,t_xx2,t_xx3" -S "mysql-bin.000019" -E "2017-03-02 13:00:00" -N "2017-03-02 14:09:00" -I -U

===log will also  write to .//mysqlbinlog_flashback.log===
parameter={'start_binlog_file': 'mysql-bin.000019', 'stream': None, 'keep_data': True,
 'file': {'data_create': None, 'flashback': None, 'data': None}, 'add_schema_name': False, 'start_time': None, 'keep_current_data': False, 'start_to_timestamp': 1488430800,
 'mysql_setting': {'passwd': 'ecuser', 'host': 'localhost', 'charset': 'utf8', 'port': 3306, 'user': 'ecuser'},
 'table_name': 't_xx1,t_xx2,t_xx3', 'skip_delete': False, 'schema': 'dbname', 'stat': {'flash_sql': {}},
 'table_name_array': ['t_xx1', 't_xx2', 't_xx3'],
 'one_binlog_file': False, 'output_file_path': './log', 'start_position': 4, 'skip_update': True,
 'dump_event': False, 'end_to_timestamp': 1488434940, 'skip_insert': True, 'schema_array': ['dbname']
}
scan 10000 events ....from binlogfile=mysql-bin.000019,timestamp=2017-03-02T11:42:14
scan 20000 events ....from binlogfile=mysql-bin.000019,timestamp=2017-03-02T11:42:29
...

提示：
binlog爲ROW格式，dml影響的每一行都會記錄兩個event：Table_map和Row_log。而table_map裏面的table_id並不會影響它在哪一個實例上應用，這個id能夠認爲是邏輯上，記錄表結構版本的機制 —— 當它在 table_definition_cache 沒有找到表定義時，id自增1，分配給要記錄到binlog的表。

mysqlbinlog_back.py 使用經驗 ：

• 務必指定庫名、代表，開始的binlog文件名，起始時間，結束時間。能夠加快scan的速度。

• 根據恢復的須要，選擇 -I, -U, -D，指定回滾哪些類型的操做。

• 若是隻是恢復部分表數據（非徹底閃回），作不到關聯表的正確恢復。好比須要恢復delete數據，但沒法恢復業務裏由於delete引發其它表更新的數據，除非徹底閃回。

• 不支持表字段是 enum 類型的，好比 t_xx3 的f_do_type字段。能夠把自建實例上的enum定義改爲int。

參考

1. http://dinglin.iteye.com/blog...

2. http://www.penglixun.com/tech...

3. http://www.cnblogs.com/yuyue2...

---

本文連接地址：http://seanlook.com/2017/03/0...