mysql replication 中主從延遲是一個比較常見的問題，請看前期一篇博文：怎樣解決MySQL數據庫主從復制延遲的問題。根據目前有些公司使用的方案，最近測試了兩個，其中之一是阿里的relay fetch ，業績說法數據預熱，當然也有其他開源類似開源工具，目前諸如mk-slave-prefetch及replication-prefetch等，感興趣可以去看看。整理的文檔主要是參考了官方的《relay fetch 讀取本地binlog 進行備庫預熱》，有些圖片直接引用，還有文字，與官方不同的是安裝過程中出現的問題及解決方式，歸納如下：
基本思路原理
在備庫sql線程執行更新之前，預先將相應的數據加載到內存中,並不能提高sql_thread線程執行sql的能力，也不能加快io_thread線程讀取日志的速度。
限制
1 目前僅支持主庫binlog ROW模式
2 表需要有主鍵或唯一索引
3 忽略test和mysql數據庫
4 如果數據庫中存在類似tbname_1、tbname_2這樣命名的多個表，但其表模式卻不相同時，請加上-t選項，例如：tb_1 tb_2 tb_3這樣命名的三個表，默認情況下，被認為是同樣模式的表，這個特點是淘寶為了適應他們自己的數據庫環境
5 默認最多支持10000個用戶表，如果學員支持更多表，可以通過修改宏MAX_TABLE_NUM來進行調整。
獲取源碼
安裝svn客戶端從下列地址獲取源碼：
svn checkout http://relay-fetch.googlecode.com/svn/trunk/
安裝編譯：
make
make的時候需要根據mysql安裝環境修改Makefile配置文件,relay-fetch依賴mysql的lib庫文件等，gcc編譯的時候指定，如下紅色標示部分：
#locate your libmysqlclient_r.so
all:
gcc -g -O0 -Wall-o relayfetch relayfetch.c -I/usr/local/mysql/include/-L/usr/local/mysql/lib -lmysqlclient_r -lpthread
clean:
rm -rf *.orelayfetch
32位系統安裝有warning ，如下
relayfetch.c: In function ‘daemon_rf’:
relayfetch.c:2599: warning: format ‘%lu’ expects type ‘longunsigned int’, but argument 4 has type ‘long long unsigned int’
relayfetch.c:2599: warning: format ‘%lu’ expects type ‘longunsigned int’, but argument 4 has type ‘long long unsigned int’
不是錯誤error，沒有太多影響
安裝完畢，在安裝目錄下運行./relayfetch –h，了解一下relayfetch 常用參數，如果報如下錯誤error while loading shared libraries: libmysqlclient.so.16/18:cannot open shared object file
應該是mysql的lib庫文件引用問題，建立如下類似軟鏈接
32位
ln -s /usr/local/mysql/lib/libmysqlclient.so.18 /usr/lib/
64位
ln -s /usr/local/mysql/lib/libmysqlclient.so.18 /usr/lib64/
使用
運行: ./relayfetch -h來獲取選項
主要選項包括：
-d debug
-D 后台運行
-p 密碼
-u 用戶名，請以root用戶運行
-P mysqld端口號
-s 整數，單位為M，當read線程超過sql線程position這么多字節數時，會等待sql線程，默認為1M
-S mysql sock文件路徑
-n worker線程數目。默認為5
-a 當seconds_behind_master大於這個值時，會喚醒relayfetch,默認為1s
-t 當使用該選項時，表明不使用分表規則（例如，表name_1 和表name_2會被視為同一類表）
我們可以通過端口號來運行
./relayfetch-uroot -t -P3306
或者通過sock來運行
./relayfetch-S /u01/mysql/run/mysql.sock -uroot
測試效果
這個效果不明顯，可能機器原因（本人測試256內存虛擬機）。請參考官方測試吧