誠然,MySQL 5.6版本也支持所謂的并行復制,但是其并行只是基于schema的,也就是基于庫的。如果用戶的MySQL數據庫實例中存在多個schema,對于從機復制的速度的確可以有比較大的幫助。MySQL 5.6并行復制的架構如下所示:
[](http://www.innomysql.net/wp-content/uploads/2015/05/MySQL_Replication_Architecture.png)
在上圖的紅色框框部分就是實現并行復制的關鍵所在。在MySQL 5.6版本之前,Slave服務器上有兩個線程I/O線程和SQL線程。I/O線程負責接收二進制日志(更準確的說是二進制日志的event),SQL線程進行回放二進制日志。如果在MySQL 5.6版本開啟并行復制功能,那么SQL線程就變為了coordinator線程,coordinator線程主要負責以前兩部分的內容:
* 若判斷可以并行執行,那么選擇worker線程執行事務的二進制日志
* 若判斷不可以并行執行,如該操作是DDL,亦或者是事務跨schema操作,則等待所有的worker線程執行完成之后,再執行當前的日志
這意味著coordinator線程并不是僅將日志發送給worker線程,自己也可以回放日志,但是所有可以并行的操作交付由worker線程完成。coordinator線程與worker是典型的生產者與消費者模型。
上述機制實現了基于schema的并行復制存在兩個問題,首先是crash safe功能不好做,因為可能之后執行的事務由于并行復制的關系先完成執行,那么當發生crash的時候,這部分的處理邏輯是比較復雜的。從代碼上看,5.6這里引入了Low-Water-Mark標記來解決該問題,從設計上看([WL#5569](http://dev.mysql.com/worklog/task/?id=5569)),其是希望借助于日志的冪等性來解決該問題,不過5.6的二進制日志回放還不能實現冪等性。另一個最為關鍵的問題是這樣設計的并行復制效果并不高,如果用戶實例僅有一個庫,那么就無法實現并行回放,甚至性能會比原來的單線程更差。而單庫多表是比多庫多表更為常見的一種情形。