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

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

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

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

MySQL 8.0中的復制性能改進

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

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

• 提交順序：這是默認的，它使用MySQL5.7中的默認機制。

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

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

基準

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

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

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

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

它能幫我什么？

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

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

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

MySQL復制中的其他更改

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

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

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

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