MySQL 5.7 並行複製

標籤：nbsp   code   target   inf   參數   lin   blank   導致   pre   

一、緣由：

　　某天看到主從複製延時的警示有點頻繁，就想著是不是徹底可以解決一下。

　　一般主從複製，有三個線程參與，都是單線程：Binlog Dump（主） ----->IO Thread （從） -----> SQL Thread（從）。複製出現延遲一般出在兩個地方

1）SQL線程忙不過來（可能需要應用資料量較大，可能和從庫本身的一些操作有鎖和資源的衝突；主庫可以並發寫，SQL線程不可以；主要原因）

2）網路抖動導致IO線程複寫延遲（次要原因）。

 

二、解決辦法：

　　MySQL從5.6開始有了SQL Thread多個的概念，可以並發還原資料，即並行複製技術。

　　MySQL 5.6中，設定參數slave_parallel_workers = 4(>1)，即可有4個SQL Thread（coordinator線程）來進行並行複製，其狀態為：Waiting for an evant from Coordinator。


但是其並行只是基於Schema的，也就是基於庫的。如果資料庫執行個體中存在多個Schema，這樣設定對於Slave複製的速度可以有比較大的提升。通常情況下單庫多表是更常見的一種情形，

那基於庫的並發就沒有卵用。其核心思想是：不同schema下的表並發提交時的資料不會相互影響，即slave節點可以用對relay log中不同的schema各分配一個類似SQL功能的線程，

來重放relay log中主庫已經提交的事務，保持資料與主庫一致。

　　在MySQL 5.7中，引入了基於組提交的並行複製（Enhanced Multi-threaded Slaves），設定參數slave_parallel_workers>0並且global.slave_parallel_type＝‘LOGICAL_CLOCK’，

即可支援一個schema下，slave_parallel_workers個的worker線程並發執行relay log中主庫提交的事務。其核心思想：一個組提交的事務都是可以並行回放（配合binary log group commit）；

slave機器的relay log中 last_committed相同的事務（sequence_num不同）可以並發執行。

　　其中，變數slave-parallel-type可以有兩個值：DATABASE 預設值，基於庫的並行複製方式；LOGICAL_CLOCK：基於組提交的並行複製方式

MySQL 5.7開啟Enhanced Multi-Threaded Slave配置：

# slave slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=16 master_info_repository=TABLE relay_log_info_repository=TABLE relay_log_recovery=ON

 

至此，MySQL徹底解決了複寫延遲問題，可喜可賀！

MySQL 5.7 並行複製