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

我們提供的服務(wù)有：成都網(wǎng)站設(shè)計、做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、臺前ssl等。為上千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的臺前網(wǎng)站制作公司

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

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

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

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

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

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

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

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

先來看一下 replication lag：

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

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

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

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

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

結(jié)果顯示：

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

名稱欄目：實例解讀：MySQL并行復(fù)制如何解決特定的主從問題？-創(chuàng)新互聯(lián)
標(biāo)題網(wǎng)址：http://chinadenli.net/article44/diciee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、定制網(wǎng)站、網(wǎng)站改版、外貿(mào)網(wǎng)站建設(shè)、移動網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)