在MySQL下主從復制的延遲問題一直是在業界內比較大的困擾，主從的延遲會因為受到網絡磁盤等等相關的因素影響，但其中最主要的影響是就是在master太過繁忙的寫入導致slave無法有效的從relay_log中讀取到最新的相關記錄，這樣對於數據實時性很高的業務來說slave的數據並不是最新的有一定的延時，此時使用主從的讀寫分離就有點顯的雞肋了，不能做到slave上能查到最新的實時數據，大多在slave上都是做一些對實時數據要求並不是很高的一些數據查詢。

而到了MySQL的5.6版本開始引入多線程的主從復制的機制，眾所周知MySQL的工作方式是單進程多線程的方式，那麽線程的多寡則會極大的影響到MySQL的效率，而在早期MySQL的主從都是由單線程進行的，使得主從復制除了相關的客觀因素外還受到自身的影響。但是在MySQL 5.6下多線程主從復制並不是做的相當完善的，因為在MySQL 5.6中主從復制的多線程是一個線程處理一個主從復制，而在絕大多數的生產環境中大多都是在一個數據庫中做大量的操作的，那麽這樣MySQL的多線程主從復制就又和以前的版本一樣都是單線程的主從復制，沒有太大的實際意義。為此在MySQL的5.7版本中對多線程主從復制來進一步的改善，在MySQL 5.7中是按照邏輯時鐘（類似CPU的處理機制）來處理多線程，甚至在半同步復制semisync中還是使用Performance Schema表來監控復制線程，所以在MySQL 5.7中主從復制直接因為MySQL自身導致的延時被極大的降低了,配置也很簡單，如下在salve中配置：

mysql> show global variables like ‘slave_parallel_workers‘;#默認是0，即單線程
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| slave_parallel_workers | 0     |
+------------------------+-------+
1 row in set (0.01 sec)
mysql> set global slave_parallel_workers = 4;#根據實際情況決定開啟多少個線程用於主從復制
1 row in set (0.01 sec)
mysql> show global variables like ‘%slave_parallel_type%‘;#默認是多線程機制是一個線程處理一個庫
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.01 sec)
mysql> stop slave;#修改多線程機制工作類型需要停止slave
Query OK, 0 rows affected (0.21 sec)
mysql> set global slave_parallel_type=‘logical_clock‘;
1 row in set (0.01 sec)
mysql> start slave;    
Query OK, 0 rows affected (0.08 sec)

此時再根據實際情況決定開啟多少個線程用於主從復制，此時在看下slave上的線程列表：

mysql> show full processlist;
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+-----------------------+
| Id | User        | Host      | db   | Command | Time | State                                                  | Info                  |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+-----------------------+
| 16 | root        | localhost | NULL | Query   |    0 | starting                                               | show full processlist |
| 29 | system user |           | NULL | Connect |    3 | Waiting for master to send event                       | NULL                  |
| 30 | system user |           | NULL | Connect |    3 | Slave has read all relay log; waiting for more updates | NULL                  |
| 31 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
| 32 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
| 33 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
| 34 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+-----------------------+
7 rows in set (0.00 sec)

這樣就成功的開啟MySQL的5.7版本多線程主從復制，在配置好後在slave的datadir目錄下會有根據slave_parallel_workers設置的線程數個數相同的線程文件：

最後再把配置好的變量參數寫入my.cnf，使得下一次重啟生效：

slave_parallel_workers = 4
slave_parallel_type= logical_clock

本文出自 “Jim的技術隨筆” 博客，謝絕轉載！

MySQL 5.7下主從復制延遲解決方案