mysql實現讀寫分離的原理

主庫記錄二進制日誌。在每次準備提交事務完成數據更新前，主庫將數據更新的事件記錄到二進制日誌中。MySQL會按事務提交的順序而非每條語句的執行順序來記錄二進制日誌。在記錄二進制日誌後，主庫會告訴存儲引擎能夠提交事務了。下一步，備庫將主庫的二進制日誌複製到其本地的中繼日誌中。首先，備庫會啓動一個工做線程，稱爲I/O線程，I/O線程跟主庫創建一個普通的客戶端鏈接，而後在主庫啓動一個特殊的二進制轉儲線程，這個二進制轉儲線程會讀取主庫上二進制日誌中的事件。他不會對事件進行輪詢。若是該線程追遇上了主庫，他將進入睡眠狀態，直到主庫發送信號量通知其有新的事件產生時纔會被喚醒，備庫I/O線程會將接收到的事件記錄到中繼日誌中。

備庫 的SQL線程執行最後一步，該線程從中繼日誌中讀取事件並在備庫執行，從而實現備庫數據的更新。當SQL線程追遇上I/O線程時，中繼日誌一般已經在系統緩存中，因此中繼日誌的開銷很低。SQL線程執行的事件也能夠經過配置選項來決定是否寫入其本身的二進制日誌中，它對於咱們稍後提到的場景很是有用。這種複製架構實現了獲取事件和重放事件的解耦，容許這兩個過程異步進行。也就是說I/O線程可以獨立於SQL線程以外工做。但這種架構也限制了複製的過程，其中最重要的一點是在主庫上併發運行的查詢在備庫只能串行化執行，由於只有一個SQL線程來重放中繼日誌中的事件。這也是不少共組歐服在的性能瓶頸所在。雖然有一些針對該問題的解決方案，但大多數用戶仍然受制於單線程。MySQL5.6之後，提供了GTID多開啓多線程同步複製的方案，即每一個庫有一個單獨的sql thread。

進行同步複製，之將大大改善MySQL主從同步的數據延遲問題，配合mycat分片，能夠更好地將一個超級大表的數據同步的時延下降到最低，此外，用GTID避免了在傳送binlog邏輯上依賴文件名和物理偏移量，可以更好的支持自動容災切換，對運維人員來講應該是一件使人高興的事情，由於傳統的方式裏，須要找到binlog和pos點，而後change master to 指向，而不是頗有經驗的運維，每每會將其找錯，形成主從同步複製報錯，在mysql5.6裏，無需再知道binlog和pos點，須要知道master的IP和端口以及帳號密碼便可，由於同步複製是自動的，mysql經過內部機制GTID自動找點同步。

即便是併發複製機制，仍然沒法避免主從數據庫的數據瞬間不一樣步的問題，所以又有了一種加強的方案，即galera for mysql、percona-cluster或者mariadb cluster等集羣機制，他們是一種多主同步複製的模式，能夠在任意節點上進行讀寫、自動控制成員、自動刪除故障節點、自動加入節點、真正給予行級別的併發複製等強大能力。