MySQL主從復(fù)制性能優(yōu)化

MySQL的主從復(fù)制的基本原理是從庫(kù)連接到主庫(kù)，主庫(kù)生成一個(gè)主庫(kù)DUMP線程，該DUMP線程的主要任務(wù)是
一直挖掘binlog日志，然后發(fā)送到從庫(kù)的IO線程,IO線程接收到日志流后，寫(xiě)入relay log,另一個(gè)線
程SQL線程,會(huì)讀取該relay log內(nèi)容，然后對(duì)sql語(yǔ)句進(jìn)行重放.

主庫(kù)DUMP線程會(huì)根據(jù)從庫(kù)傳來(lái)的文件位置信息去讀取binlog文件中的內(nèi)容，DUMP線程并不是每隔一段時(shí)間去
讀取的，而且在主庫(kù)上當(dāng)有寫(xiě)binlog日志時(shí)，會(huì)產(chǎn)生同步，那么DUMP線程根據(jù)同步機(jī)制會(huì)立即去讀取binlog
文件.當(dāng)主庫(kù)去寫(xiě)binlog時(shí)，DUMP線程去讀，問(wèn)題很快來(lái)了，這樣的情形可能會(huì)產(chǎn)生讀寫(xiě)沖突，有時(shí)候我們
也把這種情況稱為"IO抖動(dòng)",如果我們的服務(wù)器配置了RAID的cache,或是使用文件系統(tǒng)的cache,當(dāng)一個(gè)寫(xiě)操
作的時(shí)候，可能并不會(huì)真正的寫(xiě)到磁盤(pán)上去，而是寫(xiě)到cache中去了，這樣再次去讀的話，直接從cache中
讀取就可以了.

如果主庫(kù)有多個(gè)從庫(kù)，DUMP線程和服務(wù)器的寫(xiě)binlog線程，DUMP線程和DUMP線程之間讀寫(xiě)爭(zhēng)用會(huì)更加頻
繁，如果使用了SSD存儲(chǔ)，這種情況可以得到好的的緩解.

當(dāng)DUMP線程接收到同步事件后，開(kāi)始執(zhí)行DUMP操作，這時(shí)候在主庫(kù)上不應(yīng)該存在CPU負(fù)載過(guò)高，而使DUMP線程在
運(yùn)行隊(duì)列中等待時(shí)間過(guò)長(zhǎng).

對(duì)于需要binlog復(fù)制的庫(kù)，我們?cè)谥鲙?kù)使用binlog_do_db,而避免對(duì)所有的庫(kù)操作都生成binlog。不過(guò)我
在使用這個(gè)參數(shù)的時(shí)候需要小心測(cè)試，因?yàn)橛行?yīng)用寫(xiě)庫(kù)的方式可能會(huì)導(dǎo)致binlog數(shù)據(jù)丟失.

主庫(kù)DUMP線程通過(guò)網(wǎng)絡(luò)發(fā)送給從庫(kù)的IO線程，DUMP線程本身不提供壓縮功能，所以這時(shí)候足夠的帶寬變得很重
要，特別是對(duì)于跨公網(wǎng)的傳輸，另外可以通過(guò)在網(wǎng)絡(luò)層面上使用網(wǎng)絡(luò)設(shè)備自帶的壓縮的功能來(lái)彌補(bǔ)這方面的不足.

當(dāng)IO線程接收到binlog后，往relay log里面寫(xiě)數(shù)據(jù)，存儲(chǔ)本身的速度和在每次接收后是否立即同步到磁盤(pán)上
的相關(guān)參數(shù)對(duì)IO線程處理的速度變得極為重要.比如sync_relay_log,sync_master_info 和sync_relay_log_info三個(gè)參數(shù)，
具體的值可能要視環(huán)境而做出調(diào)整。比如sync_relay_log設(shè)置為0,每次接收到數(shù)據(jù)后不直接寫(xiě)磁盤(pán)，而依賴OS去刷新到磁盤(pán)上.

SQL線程的原理和DUMP線程的原理很類似，當(dāng)有relay log日志寫(xiě)入時(shí)會(huì)產(chǎn)生同步，那么SQL線程就會(huì)去讀取其中的數(shù)據(jù)進(jìn)行
重放。在MySQL 5.6中很重要的一個(gè)提升就是可以多個(gè)SQL線程可以同時(shí)工作，這樣增加了吞吐量.可以設(shè)置slave_parallel_workers
來(lái)達(dá)到這樣目的.從庫(kù)上的其他參數(shù)比如innodb_flush_log_at_trx等，雖會(huì)加快sql線程的吞吐量，但是可能需要縮合考慮
而不僅僅是針對(duì)SQL線程.