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

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

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

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

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

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

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

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

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

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

基準(zhǔn)

一位作者寫了一篇文章，他試圖衡量新模式的性能。他使用了最好的場景——沒有任何耐用性，來展示新舊模式之間的差異。我們決定使用相同的方法，這次是在一個更真實(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）上存儲了32個表中的1600萬行。我們測試了1、2、4、8、16和32個并發(fā)sysbench連接的所有模式的性能。過程如下：停止slave，執(zhí)行100k事務(wù)，啟動slave并計(jì)算清除slave延遲所需的時間。

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

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

它能幫我什么？

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

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

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

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

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

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

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

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