一、關(guān)于Transfer

MySQL-Transefer(下稱Transfer)是一個(gè)基于MySQL+patch后得到的主從同步工具。

其主要目的是為了解決原生版本的主從同步里，從庫是單線程apply主庫的binlog，導(dǎo)致的延遲。

最近完成測試的版本將multi-master (by P.Linux)合并到Transfer中并針對支付寶的應(yīng)用需求做了定制性能改進(jìn)。

這里做一個(gè)已經(jīng)完成的完整功能介紹。

二、總體結(jié)構(gòu)

說明：

1、Transfer可以注冊成多個(gè)Master的從庫

2、Transfer接收多個(gè)Master傳入的binlog后將更新執(zhí)行到Slave上

3、Transfer本地沒有數(shù)據(jù)

如果你沒有多主的需求，那結(jié)構(gòu)就是Master -> Transfer -> Slave.

三、內(nèi)部結(jié)構(gòu)

既然是單線程造成的主從延遲，提升就需要用多線程來實(shí)現(xiàn)。

我們來看單主情況下的內(nèi)部實(shí)現(xiàn)。

點(diǎn)擊放大

說明：左上角是Master， 右上角是Transfer，下面是Slave。

四、增加參數(shù)及對應(yīng)說明

在my.cnf中新增如下幾個(gè)參數(shù)：

remote_slave_hostname = Ip of Slave

remote_slave_username = root

remote_slave_password = root

remote_slave_port = Port of Slave

stop_slave_on_error = 1

remote_table_maps_file = ./table_maps

transfer_slave_thread = 10

說明:

1、 前四個(gè)是目標(biāo)slave庫的認(rèn)證信息

2、 Stop_slave_on_error 一般建議配置為1，表示只要有一個(gè)線程執(zhí)行出錯(cuò)，所有slave_io_thread都停止

3、 remote_table_maps_file路徑指向本地文件，文件中每行格式為 “表1 表2”，表示在Transfer做同步時(shí)，將Master上所有對表1的操作都更新到表2.

4、 transfer_slave_thread是一個(gè)只讀參數(shù)，控制Transfer有多少個(gè)線程做并發(fā)更新(若為1則表示串行更新，性能與官方版本相同)。一般建議配置為系統(tǒng)核數(shù)2倍。

五、一些說明

1、由于Transfer是在MySQL基礎(chǔ)上打的patch，因此支持幾乎所有MySQL的監(jiān)控命令，你原來加在Slave上的監(jiān)控，可以直接改到Transfer上。

2、 一般我們將Transfer和Slave放在同一個(gè)機(jī)器上(等于是裝兩個(gè)MySQL，一個(gè)是Transfer，一個(gè)是真正的slave)

3、 Transfer按照表名hash將不同表的更新分配到不同的線程，因此在多表環(huán)境下才能看得到性能提升

4、 Master的binlog格式必須設(shè)置成row

5、 若需要用到多個(gè)Master，給每個(gè)Master命令一個(gè)channel，命令序列為 change master channel1 to master_log_file=xxx…… ; start slave channel1; 可以單獨(dú)對一個(gè)chanel執(zhí)行start\stop等命令

6、 若只需要一個(gè)master，則語法格式不變

六、性能效果

測試場景如下，在Master上的16個(gè)表并發(fā)分別插入10w行。期間先停止同步。插入完成后，再分別測試直接用原生版本主從和Transfer的性能。

主庫插入耗時(shí)66.1s 。

耗時(shí)

平均tps

MySQL主從

363s

4402/s

Transfer同步

66s

24242/s

七、Patch應(yīng)用

下載地址。 基于5.1.48, patch –p0 < transfer_mysql.diff. 后續(xù)安裝步驟與原生MySQL相同.

示例my.cnf 從此下載，記得修改程序安裝目錄。