實(shí)例解讀：MySQL并行復(fù)制如何解決特定的主從問(wèn)題？

并行復(fù)制存世已多年，但是在實(shí)際應(yīng)用場(chǎng)景中的使用并不常見(jiàn)。這次很幸運(yùn)，我們剛好遇到一個(gè)客戶，主的寫(xiě)入工作量非常大，但是從難以跟上，在這種情況下，我建議它使用并行從屬線程。

那么，如何衡量并行復(fù)制是否在客戶的場(chǎng)景中發(fā)揮了作用?對(duì)于客戶業(yè)務(wù)能夠帶來(lái)多大的幫助?下面我們就一起來(lái)看看吧!

在客戶業(yè)務(wù)場(chǎng)景中， slave_parallel_workers 是0，很明顯我應(yīng)該去增大，但增大的幅度是多少呢?1還是10，這個(gè)問(wèn)題我們會(huì)在另一篇文章中解釋?zhuān)日f(shuō)一下本文的場(chǎng)景中，我們將slave_parallel_workers 調(diào)整到了40。

同時(shí)，我們對(duì)slave還做了以下更改：

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

40個(gè)線程聽(tīng)起來(lái)是很多，但是這是取決于特定的工作負(fù)載的，如果事務(wù)是獨(dú)立的，那么它就可能派上用場(chǎng)。

接下來(lái)，我們?cè)賮?lái)看看哪些線程在工作：

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 |
+-----------+------------+

從上述代碼中，我們可以看到哪些線程是在工作，但是這些線程真的加速?gòu)?fù)制了嗎?Slave能在同一時(shí)間內(nèi)寫(xiě)出更多的東西嗎?

先來(lái)看一下 replication lag：

我們可以看大lag很快就降下來(lái)了，這是因?yàn)榫€程數(shù)增加了嗎?還是因?yàn)樯啥鄠€(gè)插件的作業(yè)完成了，沒(méi)有更多的寫(xiě)入了?(復(fù)制延遲沒(méi)有達(dá)到0，因?yàn)檫@個(gè)Slave故意拖延了一個(gè)小時(shí)。)

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

Slave插入了比之前更多的行，那實(shí)際插入了多少行呢?下面我們創(chuàng)建一個(gè)新的圖表來(lái)查看

每小時(shí)插入了多少行。在PMM中，我們已經(jīng)擁有了所有這些信息，只需要使用下面的查詢(xún)創(chuàng)建一個(gè)新的圖表：

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

結(jié)果顯示：

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