MySQL主從復制性能優化
一直挖掘binlog日誌，然後發送到從庫的IO線程,IO線程接收到日誌流後，寫入relay log,另一個線
程SQL線程,會讀取該relay log內容，然後對sql語句進行重放.
主庫DUMP線程會根據從庫傳來的文件位置信息去讀取binlog文件中的內容，DUMP線程並不是每隔一段時間去
讀取的，而且在主庫上當有寫binlog日誌時，會產生同步，那麽DUMP線程根據同步機制會立即去讀取binlog
文件.當主庫去寫binlog時，DUMP線程去讀，問題很快來了，這樣的情形可能會產生讀寫沖突，有時候我們
作的時候，可能並不會真正的寫到磁盤上去，而是寫到cache中去了，這樣再次去讀的話，直接從cache中
讀取就可以了.
如果主庫有多個從庫，DUMP線程和服務器的寫binlog線程，DUMP線程和DUMP線程之間讀寫爭用會更加頻
繁，如果使用了SSD存儲，這種情況可以得到好的的緩解.
當DUMP線程接收到同步事件後，開始執行DUMP操作，這時候在主庫上不應該存在CPU負載過高，而使DUMP線程在
運行隊列中等待時間過長.
對於需要binlog復制的庫，我們在主庫使用binlog_do_db,而避免對所有的庫操作都生成binlog。不過我
主庫DUMP線程通過網絡發送給從庫的IO線程，DUMP線程本身不提供壓縮功能，所以這時候足夠的帶寬變得很重
要，特別是對於跨公網的傳輸，另外可以通過在網絡層面上使用網絡設備自帶的壓縮的功能來彌補這方面的不足.
當IO線程接收到binlog後，往relay log裏面寫數據，存儲本身的速度和在每次接收後是否立即同步到磁盤上
的相關參數對IO線程處理的速度變得極為重要.比如sync_relay_log,sync_master_info 和sync_relay_log_info三個參數，
具體的值可能要視環境而做出調整。比如sync_relay_log設置為0,每次接收到數據後不直接寫磁盤，而依賴OS去刷新到磁盤上.
SQL線程的原理和DUMP線程的原理很類似，當有relay log日誌寫入時會產生同步，那麽SQL線程就會去讀取其中的數據進行
重放。在MySQL 5.6中很重要的一個提升就是可以多個SQL線程可以同時工作，這樣增加了吞吐量.可以設置slave_parallel_workers
來達到這樣目的.從庫上的其他參數比如innodb_flush_log_at_trx等，雖會加快sql線程的吞吐量，但是可能需要縮合考慮
而不僅僅是針對SQL線程.
MySQL主從復制性能優化