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執行緒.