一、并行復制的背景
首先，為什么會有并行復制這個概念呢？
1. DBA都應該知道，MySQL的復制是基于binlog的。
2. MySQL復制包括兩部分，IO線程 和 SQL線程。
3. IO線程主要是用于拉取接收Master傳遞過來的binlog，并將其寫入到relay log
4. SQL線程主要負責解析relay log，并應用到slave中
5. 不管怎么說，IO和SQL線程都是單線程的，然后master卻是多線程的，所以難免會有延遲，為了解決這個問題，多線程應運而生了。
6. IO多線程？
6.1 IO沒必要多線程，因為IO線程并不是瓶頸啊
7. SQL多線程？
7.1 沒錯，目前最新的5.6，5.7，8.0 都是在SQL線程上實現了多線程，來提升slave的并發度
接下來，我們就來一窺MySQL在并行復制上的努力和成果吧
二、重點
是否能夠并行，關鍵在于多事務之間是否有鎖沖突，這是關鍵。 下面的并行復制原理就是在看如何讓避免鎖沖突
三、MySQL5.6 基于schema的并行復制
slave-parallel-type=DATABASE(不同庫的事務，沒有鎖沖突)
之前說過，并行復制的目的就是要讓slave盡可能的多線程跑起來，當然基于庫級別的多線程也是一種方式(不同庫的事務，沒有鎖沖突)
先說說優點： 實現相對來說簡單，對用戶來說使用起來也簡單
再說說缺點： 由于是基于庫的，那么并行的粒度非常粗，現在很多公司的架構是一庫一實例，針對這樣的架構，5.6的并行復制無能為力。當然還有就是主從事務的先后順序，對于5.6也是個大問題
話不多說，來張圖好了
四、MySQL5.7 基于group commit的并行復制
slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一組的事務[last-commit相同]，沒有鎖沖突. 同一組，肯定沒有沖突，否則沒辦法成為同一組)
slave-parallel-type=LOGICAL_CLOCK : Lock-Based模式(即便不是同一組的事務，只要事務之間沒有鎖沖突[prepare階段]，就可以并發。 不在同一組，只要N個事務prepare階段可以重疊，說明沒有鎖沖突)
group commit，之前的文章有詳細描述，這里不多解釋。MySQL5.7在組提交的時候，還為每一組的事務打上了標記，現在想想就是為了方便進行MTS吧。
我們先看一組binlog
| last_committed=0 sequence_number=1last_committed=1 sequence_number=2last_committed=2 sequence_number=3last_committed=3 sequence_number=4last_committed=4 sequence_number=5last_committed=4 sequence_number=6last_committed=4 sequence_number=7last_committed=6 sequence_number=8last_committed=6 sequence_number=9last_committed=9 sequence_number=10 |
