實例解讀：MySQL并行復制如何解決特定的主從問題？

并行復制存世已多年，但是在實際應用場景中的使用并不常見。這次很幸運，我們剛好遇到一個客戶，主的寫入工作量非常大，但是從難以跟上，在這種情況下，我建議它使用并行從屬線程。

那么，如何衡量并行復制是否在客戶的場景中發揮了作用?對于客戶業務能夠帶來多大的幫助?下面我們就一起來看看吧!

在客戶業務場景中， slave_parallel_workers 是0，很明顯我應該去增大，但增大的幅度是多少呢?1還是10，這個問題我們會在另一篇文章中解釋，先說一下本文的場景中，我們將slave_parallel_workers 調整到了40。

同時，我們對slave還做了以下更改：

slave_parallel_type = LOGICAL_CLOCK;
slave_parallel_workers = 40;
slave_preserve_commit_order = ON;

40個線程聽起來是很多，但是這是取決于特定的工作負載的，如果事務是獨立的，那么它就可能派上用場。

接下來，我們再來看看哪些線程在工作：

mysql> SELECT performance_schema.events_transactions_summary_by_thread_by_event_name.THREAD_ID AS THREAD_ID
, performance_schema.events_transactions_summary_by_thread_by_event_name.COUNT_STAR AS COUNT_STAR
FROM performance_schema.events_transactions_summary_by_thread_by_event_name
WHERE performance_schema.events_transactions_summary_by_thread_by_event_name.THREAD_ID IN
(SELECT performance_schema.replication_applier_status_by_worker.THREAD_ID
FROM performance_schema.replication_applier_status_by_worker);
+-----------+------------+
| THREAD_ID | COUNT_STAR |
+-----------+------------+
| 25882 | 442481 |
| 25883 | 433200 |
| 25884 | 426460 |
| 25885 | 419772 |
| 25886 | 413751 |
| 25887 | 407511 |
| 25888 | 401592 |
| 25889 | 395169 |
| 25890 | 388861 |
| 25891 | 380657 |
| 25892 | 371923 |
| 25893 | 362482 |
| 25894 | 351601 |
| 25895 | 339282 |
| 25896 | 325148 |
| 25897 | 310051 |
| 25898 | 292187 |
| 25899 | 272990 |
| 25900 | 252843 |
| 25901 | 232424 |
+-----------+------------+

從上述代碼中，我們可以看到哪些線程是在工作，但是這些線程真的加速復制了嗎?Slave能在同一時間內寫出更多的東西嗎?

先來看一下 replication lag：

我們可以看大lag很快就降下來了，這是因為線程數增加了嗎?還是因為生成多個插件的作業完成了，沒有更多的寫入了?(復制延遲沒有達到0，因為這個Slave故意拖延了一個小時。)

幸運的是，在PMM中我們還有其他圖表可以看，例如顯示InnoDB Row操作：

Slave插入了比之前更多的行，那實際插入了多少行呢?下面我們創建一個新的圖表來查看

每小時插入了多少行。在PMM中，我們已經擁有了所有這些信息，只需要使用下面的查詢創建一個新的圖表：

increase(mysql_global_status_innodb_row_ops_total{instance="$host",operation!="read"}[1h])

結果顯示：

從圖中我們可以看到每小時插入行數大幅增加，從每小時約50Mil到200-400Mil。我們可以得出結論，增加slave_parallel_workers數量確實有幫助。