[MySQL 工具] 備庫預熱工具relayfetch及錯誤處理工具seh

今年上半年，由于線上許多執行個體存在主備延遲，并且經常有備庫複制中斷導緻dba同學需要半夜起來處理，出于這樣的需求，是以寫了這兩個工具，不過嚴格來講，seh算是relayfetch的衍生品。

兩個工具都可以從如下位址checkout：

<a href="http://code.google.com/p/relay-fetch/">http://code.google.com/p/relay-fetch/</a>

由于在備庫上（尤其是沒有讀寫負載的備庫）sql線程是單線程的，比較悲觀的情況是，需要從磁盤讀取資料，然後再做dml。當資料量遠大于buffer pool的大小時，這種磁盤io開銷尤為明顯。

通常的作法是将binlog中的事件轉換成select操作，目前社群也有很多類似的工具，不過都是隻支援statement模式，如果你是基于statement模式複制的話，可以在主備産生延遲時，挑一個用。

為了不重複發明輪子，relayfetch主要用于支援row模式(隻支援簡單的statement模式，沒做充分測試)，通過解析binlog中的delete_rows_event/update_rows_event/write_rows_event，擷取其中的primary key和unique key，然後轉換成select語句，使用多線程執行select，預設5個線程，能夠控制預熱不會“走的太快”。

當然備庫預熱并不總是有效果的，也有一些限制：

1、如果buffer pool足夠大到容納大部分資料/熱點資料的話，可能沒什麼效果（瓶頸不在磁盤io）

2、需要有主鍵或者唯一鍵

3、對insert操作産生的延遲預熱效果不明顯，尤其是連續插入（但對存在多個唯一鍵(包括主鍵)會有不錯的效果，因為按照主鍵順序插入時，唯一鍵上的insert可能是随機的io）

4、目前主要針對row模式預熱，基于statement模式的同學請自行谷歌目前社群的預熱工具

寫這個工具的初衷是由于各種原因（複制bug，人為失誤，主備切換導緻資料丢失等等。。。）備庫經常會出現複制中斷，duplicate key和key not found錯誤應該是比較常見的（對應的錯誤碼為1062和1032）

通常的處理辦法是設定sql_slave_skip_counter來跳過錯誤，但這樣明顯的會産生主備資料不一緻。seh不是跳過錯誤，而是将導緻錯誤的資料補上。

seh通過解析binlog，找到發生錯誤的事件，對于找不到鍵的錯誤，将相應的記錄補上。代碼裡面還實作了處理重複鍵的代碼，不過沒有開啟（删除記錄太暴力。。。。），對于重複鍵錯誤，如果是插入操作導緻的，可以通過将slave_exec_mode設定為idempotent來解決。

同樣seh需要表上有主鍵存在，并且無法處理同時存在主鍵錯誤和唯一鍵沖突的情況，例如丢失的記錄上如果有唯一鍵并且和已有記錄沖突時，就會補資料失敗。

有興趣的同學可以玩一下這兩個工具，有問題的話可以在google code上送出issue，或郵件我.