MySQL主從復制性能優化

MySQL的主從復制的基本原理是從庫連接到主庫，主庫生成一個主庫DUMP線程，該DUMP線程的主要任務是
一直挖掘binlog日志，然后發送到從庫的IO線程,IO線程接收到日志流后，寫入relay log,另一個線
程SQL線程,會讀取該relay log內容，然后對sql語句進行重放.

主庫DUMP線程會根據從庫傳來的文件位置信息去讀取binlog文件中的內容，DUMP線程并不是每隔一段時間去
讀取的，而且在主庫上當有寫binlog日志時，會產生同步，那么DUMP線程根據同步機制會立即去讀取binlog
文件.當主庫去寫binlog時，DUMP線程去讀，問題很快來了，這樣的情形可能會產生讀寫沖突，有時候我們
也把這種情況稱為"IO抖動",如果我們的服務器配置了RAID的cache,或是使用文件系統的cache,當一個寫操
作的時候，可能并不會真正的寫到磁盤上去，而是寫到cache中去了，這樣再次去讀的話，直接從cache中
讀取就可以了.

如果主庫有多個從庫，DUMP線程和服務器的寫binlog線程，DUMP線程和DUMP線程之間讀寫爭用會更加頻
繁，如果使用了SSD存儲，這種情況可以得到好的的緩解.

當DUMP線程接收到同步事件后，開始執行DUMP操作，這時候在主庫上不應該存在CPU負載過高，而使DUMP線程在
運行隊列中等待時間過長.

對于需要binlog復制的庫，我們在主庫使用binlog_do_db,而避免對所有的庫操作都生成binlog。不過我
在使用這個參數的時候需要小心測試，因為有些應用寫庫的方式可能會導致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線程.