MySQL中的復(fù)制已經(jīng)存在了很長(zhǎng)一段時(shí)間，并且在過(guò)去的幾年中一直在穩(wěn)步改進(jìn)。它更像是進(jìn)化而不是革命。這是完全可以理解的，因?yàn)閺?fù)制是許多人依賴的一個(gè)重要特性—它必須工作。

在最近的MySQL版本中，我們看到了通過(guò)支持并行應(yīng)用事務(wù)來(lái)提高復(fù)制性能。在MySQL5.6中，并行化是在模式級(jí)別完成的——所有在不同模式中執(zhí)行的事務(wù)都可以一次執(zhí)行。對(duì)于那些在一臺(tái)服務(wù)器上有多個(gè)模式的工作負(fù)載來(lái)說(shuō)，這是一個(gè)很好的改進(jìn)，而且負(fù)載或多或少地均勻分布在這些模式上。

在MySQL 5.7中，增加了另一種并行化方法，即所謂的“邏輯時(shí)鐘”。它允許在從屬服務(wù)器上獲得某種程度的并發(fā)性，即使您的所有數(shù)據(jù)都存儲(chǔ)在單個(gè)模式中。簡(jiǎn)而言之，它基于這樣一個(gè)事實(shí)：由于硬件增加了延遲，一些事務(wù)將一起提交。您甚至可以手動(dòng)添加延遲，以便使用binlogu groupu commitu syncu delay在從屬服務(wù)器上實(shí)現(xiàn)更好的并行化。

這個(gè)解決方案真的很好，但不是沒(méi)有缺點(diǎn)。提交事務(wù)的每一次延遲最終都會(huì)影響應(yīng)用程序中面向用戶的部分。當(dāng)然，你可以在幾毫秒的范圍內(nèi)設(shè)置延遲，但即便如此，還是會(huì)有額外的延遲減慢應(yīng)用程序的速度。

MySQL 8.0中的復(fù)制性能改進(jìn)

MySQL8.0目前（2017年8月）仍處于測(cè)試狀態(tài)，它為復(fù)制帶來(lái)了一些不錯(cuò)的改進(jìn)。最初，它是為組復(fù)制（GR）而開(kāi)發(fā)的，但由于GR在后臺(tái)使用常規(guī)復(fù)制，“普通”MySQL復(fù)制從中受益。我們提到的改進(jìn)是二進(jìn)制日志中存儲(chǔ)的依賴跟蹤信息。MySQL8.0現(xiàn)在有了一種方法來(lái)存儲(chǔ)關(guān)于哪些行受給定事務(wù)影響的信息（稱為writeset），并比較不同事務(wù)的writeset。這使得識(shí)別那些不在同一行子集上工作的事務(wù)成為可能，因此，這些事務(wù)可以并行應(yīng)用。與MySQL5.7中的實(shí)現(xiàn)相比，這可以使并行化級(jí)別提高幾倍。您需要記住的是，最終，從機(jī)將看到不同的數(shù)據(jù)視圖，一個(gè)從未出現(xiàn)在主機(jī)上的視圖。這是因?yàn)閼?yīng)用事務(wù)的順序可能與應(yīng)用于主機(jī)的順序不同。不過(guò)，這應(yīng)該不是問(wèn)題。MySQL5.7中當(dāng)前多線程復(fù)制的實(shí)現(xiàn)也可能導(dǎo)致此問(wèn)題，除非顯式啟用slave preserve commit order。

為了控制這種新的行為，引入了變量binlogu transactionu dependencyu tracking。它可以有三個(gè)值：

• 提交順序：這是默認(rèn)的，它使用MySQL5.7中的默認(rèn)機(jī)制。

• 寫集：它可以實(shí)現(xiàn)更好的并行化，并且主服務(wù)器開(kāi)始將寫集數(shù)據(jù)存儲(chǔ)在二進(jìn)制日志中。

• 寫集會(huì)話：這確保事務(wù)將按順序在從服務(wù)器上執(zhí)行，并解決從服務(wù)器看到的問(wèn)題數(shù)據(jù)庫(kù)的一種從未在主機(jī)上出現(xiàn)過(guò)的狀態(tài)被消除。它減少了并行化，但仍能提供比默認(rèn)設(shè)置更好的吞吐量。

基準(zhǔn)

一位作者寫了一篇文章，他試圖衡量新模式的性能。他使用了最好的場(chǎng)景——沒(méi)有任何耐用性，來(lái)展示新舊模式之間的差異。我們決定使用相同的方法，這次是在一個(gè)更真實(shí)的設(shè)置中：二進(jìn)制日志啟用了logu-slave-u更新。耐久性設(shè)置保留為默認(rèn)值（因此，syncu binlog=1-這是MySQL8.0中的新默認(rèn)值，啟用了doublewrite緩沖區(qū)，啟用了InnoDB校驗(yàn)和等）耐久性中唯一的例外是InnoDBu flushu logu atu trxu commit設(shè)置為2。

我們使用m4.2xl實(shí)例、32G、8核（因此slaveu parallelu workers設(shè)置為8）。我們還使用了sysbench，oltpu read_寫入.lua腳本。在1000gbgp2卷（即3000 IOPS）上存儲(chǔ)了32個(gè)表中的1600萬(wàn)行。我們測(cè)試了1、2、4、8、16和32個(gè)并發(fā)sysbench連接的所有模式的性能。過(guò)程如下：停止slave，執(zhí)行100k事務(wù)，啟動(dòng)slave并計(jì)算清除slave延遲所需的時(shí)間。

首先，我們不知道當(dāng)sysbench只使用一個(gè)線程執(zhí)行時(shí)發(fā)生了什么。每項(xiàng)測(cè)試在預(yù)熱運(yùn)行后執(zhí)行五次。這個(gè)特定的配置被測(cè)試了兩次——結(jié)果是穩(wěn)定的：?jiǎn)尉€程工作負(fù)載是最快的。我們將進(jìn)一步調(diào)查，以了解發(fā)生了什么。

除此之外，其余結(jié)果與我們的預(yù)期相符。提交順序是最慢的，特別是對(duì)于低流量、2-8個(gè)線程。WRITESETu會(huì)話通常比COMMITu順序執(zhí)行得更好，但對(duì)于低并發(fā)流量，它比WRITESET慢。

它能幫我什么？

第一個(gè)優(yōu)點(diǎn)是顯而易見(jiàn)的：如果您的工作負(fù)載很慢，而從屬服務(wù)器在復(fù)制方面卻有后退的趨勢(shì)，那么一旦主服務(wù)器升級(jí)到8.0，它們就可以從改進(jìn)的復(fù)制性能中獲益。這里有兩個(gè)注意事項(xiàng)：第一，這個(gè)特性是向后兼容的，5.7從屬也可以從中受益。第二，提醒您8.0仍處于beta測(cè)試狀態(tài)，我們不鼓勵(lì)您在生產(chǎn)中使用beta軟件，盡管急需，但這是一個(gè)測(cè)試選項(xiàng)。此功能不僅可以在從屬服務(wù)器落后時(shí)幫助您。他們可能會(huì)被完全趕上，但當(dāng)你創(chuàng)建一個(gè)新的奴隸或重組現(xiàn)有的一個(gè)，奴隸將落后。能夠使用“WRITESET”模式將使配置新主機(jī)的過(guò)程更快。

總而言之，這個(gè)特性將產(chǎn)生比你想象的更大的影響。當(dāng)MySQL處理低并發(fā)流量時(shí)，所有的基準(zhǔn)測(cè)試都顯示出性能的下降，任何有助于在這樣的環(huán)境中加速?gòu)?fù)制的東西都是一個(gè)巨大的改進(jìn)。

如果您使用中間主控形狀，這也是要查找的功能。任何中間主機(jī)都會(huì)在處理和執(zhí)行事務(wù)的方式中添加一些序列化—在現(xiàn)實(shí)世界中，中間主機(jī)上的工作負(fù)載幾乎總是不如主機(jī)上的并行。利用writesets實(shí)現(xiàn)更好的并行化，不僅可以提高中間主機(jī)的并行化，而且可以提高所有從機(jī)的并行化。甚至可以使用8.0中間主服務(wù)器來(lái)提高從屬服務(wù)器的復(fù)制性能（請(qǐng)記住，MySQL5.7從屬服務(wù)器可以理解writeset數(shù)據(jù)并使用它，即使它不能自己生成數(shù)據(jù)）。當(dāng)然，從8.0復(fù)制到5.7聽(tīng)起來(lái)相當(dāng)棘手（這不僅僅是因?yàn)?.0仍然是beta版）。在某些情況下，這可能會(huì)起作用，并會(huì)加快5.7從屬服務(wù)器上的CPU利用率。

MySQL復(fù)制中的其他更改

引入writesets雖然是最有趣的，但它并不是MySQL 8.0中MySQL復(fù)制的唯一變化。讓我們看看其他一些，也是重要的變化。如果您使用的主機(jī)比MySQL5.0舊，那么8.0將不支持其二進(jìn)制日志格式。我們不希望看到很多這樣的設(shè)置，但是如果您使用一些非常舊的MySQL進(jìn)行復(fù)制，那么肯定是時(shí)候升級(jí)了。

默認(rèn)值已更改，以確保復(fù)制盡可能安全：masteru infou repository和relayu logu infou repository設(shè)置為TABLE。Expireu log u days也已更改-現(xiàn)在默認(rèn)值為30。除了expire log days之外，還添加了一個(gè)新變量binlog expire log seconds，它允許更細(xì)粒度的binlog循環(huán)策略。在二進(jìn)制日志中添加了一些額外的時(shí)間戳，以提高復(fù)制延遲的可觀察性，引入了微秒級(jí)的粒度。

當(dāng)然，這并不是一個(gè)完整的與MySQL復(fù)制相關(guān)的更改和特性列表。如果您想了解更多信息，可以查看MySQL變更日志。確保您已經(jīng)審閱了所有這些特性—到目前為止，所有8.0版本中都添加了這些特性。

正如您所看到的，MySQL復(fù)制仍在發(fā)生變化并變得更好。正如我們?cè)谝婚_(kāi)始所說(shuō)，這必須是一個(gè)緩慢的過(guò)程，但看到未來(lái)的發(fā)展真的很棒。在“常規(guī)”MySQL復(fù)制中，還可以看到組復(fù)制的工作逐漸深入并重用。