并行復(fù)制配置與調(diào)優(yōu)

master_info_repository

開(kāi)啟MTS功能后，務(wù)必將參數(shù)master_info_repostitory設(shè)置為T(mén)ABLE，這樣性能可以有50%~80%的提升。這是因?yàn)椴⑿袕?fù)制開(kāi)啟后對(duì)于元master.info這個(gè)文件的更新將會(huì)大幅提升，資源的競(jìng)爭(zhēng)也會(huì)變大。在之前InnoSQL的版本中，添加了參數(shù)來(lái)控制刷新master.info這個(gè)文件的頻率，甚至可以不刷新這個(gè)文件。因?yàn)樗⑿逻@個(gè)文件是沒(méi)有必要的，即根據(jù)master-info.log這個(gè)文件恢復(fù)本身就是不可靠的。在MySQL 5.7中，Inside君推薦將master_info_repository設(shè)置為T(mén)ABLE，來(lái)減小這部分的開(kāi)銷(xiāo)。

slave_parallel_workers

若將slave_parallel_workers設(shè)置為0，則MySQL 5.7退化為原單線程復(fù)制，但將slave_parallel_workers設(shè)置為1，則SQL線程功能轉(zhuǎn)化為coordinator線程，但是只有1個(gè)worker線程進(jìn)行回放，也是單線程復(fù)制。然而，這兩種性能卻又有一些的區(qū)別，因?yàn)槎嗔艘淮蝐oordinator線程的轉(zhuǎn)發(fā)，因此slave_parallel_workers=1的性能反而比0還要差，在Inside君的測(cè)試下還有20%左右的性能下降，如下圖所示：

這里其中引入了另一個(gè)問(wèn)題，如果主機(jī)上的負(fù)載不大，那么組提交的效率就不高，很有可能發(fā)生每組提交的事務(wù)數(shù)量?jī)H有1個(gè)，那么在從機(jī)的回放時(shí)，雖然開(kāi)啟了并行復(fù)制，但會(huì)出現(xiàn)性能反而比原先的單線程還要差的現(xiàn)象，即延遲反而增大了。聰明的小伙伴們，有想過(guò)對(duì)這個(gè)進(jìn)行優(yōu)化嗎？

Enhanced Multi-Threaded Slave配置

說(shuō)了這么多，要開(kāi)啟enhanced multi-threaded slave其實(shí)很簡(jiǎn)單，只需根據(jù)如下設(shè)置：

# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON