演講實錄：MySQL 8.0 中的複製技術，mysql8.0

演講實錄：MySQL 8.0 中的複製技術，mysql8.0

在近期的第七屆資料技術嘉年華上，甲骨文MySQL研發工程師宋利兵做了“MySQL-8.0中的複製技術”為主題的演講，介紹了MySQL-8.0中非同步複製和Group Replication複製的發展方向，和已經實現了的新技術新特點。我們再次分享出來，希望對各位有所指導借鑒。

複製的簡介和架構

01

定義

02

MySQL複製技術的簡單架構

首先在複製環境中，有兩個server,在第一個server中產生binary log,通常將這一個server成為master，另外一台server會將master上的binary log複製過去，然後通過日誌的應用，產生和master一樣的資料庫，這就是複製的基本理論。其基本流程如下：

當應用在master資料庫上執行SQL語句，這些操作會被資料庫捕捉並以event的形式寫到binary log裡面，並以檔案的形式儲存。通過通訊模組，這些event會被發送到swill上，swill上的接收線程，接收到這些event，然後儲存到Redo log,接著由讀取線程，讀取這些event，並行地在複製資料庫中執行，這樣就產生和master一樣的資料庫。

binary log是MySQL複製的基礎，MySQL的這些日誌稱為邏輯日誌，裡面記錄的是SQL語句層級的，操作的是表中的行資料，它不關心資料在引擎裡面是怎麼儲存的，儲存格式是什麼樣的。

binary log有兩種模式

一種是ROW format

一種是statement的格式

statement的格式很好理解，就是當SQL語句執行的時候，將語句以文本的形式儲存在event裡面，然後在slave上也是以SQL語句執行。 ROW格式是針對動作表的DML語句，ROW格式不記錄原始的語句，而是把涉及到的行的內容記錄到event裡面去。兩者相比，ROW格式的安全性更高，而statement的話有時候是依賴於環境的，比如會使用到隨機數函數，這些函數在master和slave上執行的結果可能是不一致的，用ROW格式表示的是最後的結果，直接將最終的資料複製過去，所以不會產生這個問題。

另外ROW格式到slave上不需要做SQL解析，效能會更好一些。在8.0版本中，預設的格式就是ROW的格式。

對於event，是由SQL語句組成的，是語句層級的。一般一個事務由很多個event構成。 一般在事務的開頭，會有一個CTID event，這是一個全域唯一的ID號，接下來是一個begin的event，接下來是一系列的語句產生的event，最後以一個commit 的event構成。

對於ddl語句來說的話，就沒有begin和commit。

我們看到，在binary log中儲存的時候，一個事務是一個最小的儲存單位，事務裡面所有的語句都是順序的，連續第儲存在日誌中的，不會出現兩個事務的event穿插在一起。 除了事務產生的event之外，還有一些event是用來做控制的。

03

複製的三種模式

在很早以前，MySQL就引入了非同步複製，從3.23的版本就開始了。非同步複製是為MySQL的使用，以及保障MySQL中資料的高可用起到了很直觀的作用。一直到現在，也一直在使用非同步複製的模式，隨著使用者越來越多，使用情境越來越多，對複製技術也提出了更高的要求。在之前的非同步複製模式中，事務的執行過程與語句的傳輸過程是完全隔離開的。master只管做它的操作，而不用去在乎資料是否傳輸到slave了。 這樣的模式在一些對資料的可靠性要求很高的情境就會有問題，有可能會出現，使用者發現我的資料都已經提交了，但是如果當master節點宕機切換到slave節點後，使用者的資料不存在。

因此在5.5版本中引入了半同步複製，在半同步的極致中，事務執行的過程與event傳輸的過程是相關的，在master上，事務在寫完bin log之後，是不會立即提交的，要等待它所產生的event已經被複製到其他節點之後並且其他節點已經給了應答，才會進行提交，這樣就能保證所有使用者提交的資料都能夠在其他節點看到，這樣可靠性就更高。

在5.7.17版本中，引入了新的複製模式叫做 group replication，在8.0中也有保留，GR和非同步複製，和半同步複製比起來的話，有三個很明顯的優勢：

一是可靠性更高，主要體現在 GR中不會出現腦裂的情況。或者當網路中出現腦裂的情況的時候，不會產生不一致的資料，可以保障資料的一致性；

二是GR可以多寫，支援多個節點或者所有的節點同時寫。但並不會產生不一致的資料。

三是GR有組的概念，因此有許多組的自我管理的功能，在前兩種複製方法中，都需要第三方的工具揮著程式來維護節點間的操作，比如做failover的時候，而在GR中，這些管理自己都可以完成。因此特別適合當前的大規模資料使用MySQL叢集。

典型的使用情境

隨著互連網的發展，雲端運算的發展，現在MySQL大部分都是採用叢集的方式提供服務，因此叢集使用MySQL的時候會有很多新的要求和特點。我接下來將會分幾個類別介紹MySQL使用叢集的情境。

01

replicate

這是最基本的一種，也就是高可用的架構。

高可用在以前都是使用非同步複製和半同步複製，隨著8.0的發布，GR方案越來越成熟，我們可以預計到更多的使用者是使用group replication來作為最基本的高可用單元，由於上述提到的三個比較明顯的優勢，我們也推薦使用GR。

02

Automate

第二點，在大規模的使用叢集的時候，我們也期望通過自動化來減少人力成本並提高效率。在GR中，本身就包含了許多自動化的功能。這主要是得益於組的概念，在整個叢集中，每個節點都知道自己是在一個組裡面，也能夠知道所有其他節點的狀態資訊，因為他們之間是相互連訊的。在這種情況下，如果是出現了主節點的宕機，其他節點都會儘快感知到，並重新選出新的節點作為主節點。

GR的多寫有兩種模式，單組的模式主要用於非同步方式的替代。在非同步複製裡面，如果宕機的話，還需要通過工具或者程式去檢測宕機，但GR能夠自己感知到。並且不會出現兩個節點同時線上或者資料不一致的情況。

03

資料的整合——Integrate

在資料庫中儲存了大量的資料，現在越來越多的企業在做資料的分析，在MySQL 的GR中，一種方案是是binary Log中的資料匯出來，並重新匯入到其他的平台進行分析，在這個過程中，我們加入了很多的中繼資料資訊進來，讓使用者更好地瞭解資料所代表的含義。方便使用者做相應的資料轉換。

04

做遠端災備

對於物理距離跨度較大的，可以通過非同步複製方式進行傳輸，對於大批量的資料讀取，在效能上也有較大的提升。

GR是一個基礎的高可用的架構，也可以在此基礎上，做一些讀資料的效能擴充。但這方面會受到一定的限制。

由於存在組的管理，如果要將組裡面的資料複製出去，或者從其他節點把資料複製到組裡面，都是支援的，因此可以很方便地結合非同步複製和Group Replication的使用。

當然，MySQL一直在致力於做一個完整的解決方案，因此推出了 InnoDB Cluster，InnoDB包括的組件有：shell, rooter，還有以 group replication為核心的高可用的叢集，因為GR知道組的概念，因此在shell裡面整合了Cluster的概念在裡面，包含 Cluster管理的功能和命令，因此在部署InnoDB d cluster會很簡單容易，而通過rooter則實現負載平衡，讀寫分離等功能。這樣就構成了一個完整的資料庫的叢集系統，而不需要任何的第三方工具。

8.0中的新特性

接下來我們介紹8.0中在複製技術上的新特性。

主要包含以下幾個方面：

01

binary log中的中繼資料

中繼資料的作用一方面是讓使用者更方便地抽取資料，另外對於MySQL自身的複製也有協助，比如說可以做字元集的轉換，可以很準確地判斷master和slave的資料類型是否一致，當然這些功能目前還沒有完全實現，目前只是在binary log裡面放置了更豐富的中繼資料資訊。

這些中繼資料主要分為兩類。

一類是在GTID event裡面增加了中繼資料。另一個是事務的長度，也就是事務中所包含的所有event加起來的長度。還增加了commit event中的時間戳記。這裡的時間錯是毫秒層級的，方便我們監控資料複製的延遲。

第二類是table map event主要是增加了各個欄位的具體類型，有沒有符號，所屬的字元集，還包括列的名字，主鍵，枚舉型和集合型的字串的值。都會記錄到中繼資料資訊裡面。這樣在抽取資料的時候就可以準確地知道資料的類型，會非常方便。

02

操作上的新特性

這裡有一個很重要的就是多元複製，利用多元複製的很多情境就是主要用來做資料的彙總，有一種情境是我只要某個表的一部分資料，或者是一些做了分區的表，如果需要做彙總的話，就首先需要做過濾，而在8.0中，主要是在過濾功能上做了很多增強。每個通道可以設定自己的過濾策略。

例如在圖中，在A節點有三張表，B節點有其他的表，可以單獨制定規則為：從A到B的資料複製，三張表全部複製，而從B到C的通道，則指定規則為不複製user的表。

而Group Replication則會保護資料系統，保證每個節點都不會被意外地更新。

一個節點要加入到組裡面再到生效，是需要一個過程的。首先要將節點加入到網路裡面，使節點能夠互相感知，之後才能加入到組裡面。有可能在加入網路之後，還沒有加入到組裡面，此時應用已經發現了這個節點，或者直接將資訊發給這個新的節點了，這時候很可能會產生資料不一致。

因此為了保證組內節點間資料的一致性，需要在將節點加入網路前先將其屬性設定為 read-only,而等他加入之後，會根據自己的角色，自動地進行角色的切換，也就是說不需要將它read-only的屬性再手動修改。比如如果它在組中是slave角色，就保持read-only，如果它被選為master，則會切換為read-write。

當一個節點離開組的時候也是一樣的原理，會自動切換自己的屬性。也就是說當它不再組中的時候，如果管理員忘記將它刪除，也沒有關係，因為它的屬性會自動被切換為read-only，即使把資料發給它，它也不會接收的。

叢集裡面有很多的機器，這些機器之間，可能他們的機器配置，地理位置等資訊都是不一樣的，這時候使用者可能有不同的資料操作需求，比如需要特定地理位置的，或者特定配置的。希望將這些具有某些相同屬性的節點選為組，因此在8.0中增加了一個功能就是使用者可以設定每個節點的權重，這個參數就是 Group Replication Election Weights,可以對每個節點做獨立的權重配置，在選舉的時候，權重最大的節點會被選取為master節點。

03

句群管理的流控機制

在叢集中，我們希望各個節點間的資料都是同步的，沒有延遲。但可能因為一些意外的情況導致資料延遲，因此我們加入了更多的參數在裡面，使用者只需要對參數進行調整和配置。當叢集發現存在資料不同步的現象時，會自動地做流控。

04

監控方面的新特性

剛才我們提到了在GTID的event裡面加了commit的時間戳記，這個時間戳記是毫秒級的，因此可以在毫秒層級監控複製的延遲。有兩個時間戳記，第一個是最初產生事務的event對應的時間戳記，所有的節點在完成事務，在記錄binary log的時候，會把這個時間戳記保留。另外在節點上，還會記錄一個自己的時間戳記。因此，通過對比就可以知道兩個節點之間的延遲。這樣就可以方便地監控每兩個節點之間資料轉送的延遲.

在組之間的節點資料同步方面，一般來說，對於一些商務邏輯複雜的， 比如節點在加入組的時候，對於新節點的資料複製，本身就是通過非同步複製來完成的。8.0中對於Group replication的監控也做了一些增強，在replication Group Member的表，增加了一些欄位，可以在任何節點上查到所有節點的狀態資訊。能夠更好地監控群組成員的資訊，包括哪個節點是master，哪個節點是slave，所有節點的版本資訊。 

05

效能方面的新特性

在效能上最重要的一個特性是基於 writeset的並發策略。

writeset本質上就是基於主鍵的，或者說是基於行的並發策略。如果兩個事務修改了不同行的資料，由於主鍵不同，就可以並發執行。在此時執行就會有一個明顯的特點。當master上只有一個線程的時候，在slave上的並發執行效能會比較高，比master上會高很多，master上只有少數的線程，並發量不是很大的時候，slave上的效能頁還保持較好，這是因為在一個線程上的事務，只要是修改不同的行，互相不會影響的。因此基於writeset的並發機制，在slave上都會以最大並發的方式執行。

在有些使用者情境下，我們可能會希望同一個session裡面，不能做並發執行。因為可能與某些商務邏輯衝突。因此還有基於writeset的另一種機制。會判斷是否是同一個session的事務。如果是同一個session的，則會進行順序執行。

writeset最大的好處是：當slave要追master的資料，或者建立了一個新的slave需要同步之前的資料的時候，可以極大地提高效能。

以下是不使用和使用writeset的效能對比測試。

總的來說，當master上的線程數量不是很多的時候，writeset會起到比較好的效能改善作用。

06

針對JSON文檔支援的一個新特性

JSON在MySQL中本質上是以block或者text的欄位形式來儲存的，一般會比較大，但我們在更新的時候常常只更新其中很小的一部分。以前在更新的時候，會把整個欄位都儲存到binary log中再進行修改，這樣佔用的空間就比較大。如果應用完全使用JSON的方式的話，就會造成很大的空間浪費。在8.0 中，在將內容加入到binary log之前會檢測，這個欄位到底更新了多少，在binary log中只記錄一部分。

從可以看出，對於空間的節省還是很明顯的。以下是對partial JSON的效能測試結果：根據JSON對象修改的比例，效能也有一些差異。

07

其他方面的新特性

MySQL後續的版本計劃

最終期望達到的目標

更多內容請關注公眾號後回複關鍵字“2017DTC”擷取嘉賓演講視頻。

隨著技術的發展，資料在企業中的價值日益凸顯，由ACOUG和雲和恩墨主辦的資料技術嘉年華，圍繞資料及資料庫領域的核心技術，分享前沿資訊、乾貨技術，企業變革之路與戰略方向，邀你一起探索資料價值，共創未來！ 第八屆資料技術嘉年華將於2018年11月16日盛大開幕，精彩等你來！

相關閱讀：

從商用到開源：DB2遷移至MySQL的最佳實務

MySQL 傳統複製中常見故障處理和結構最佳化案例分析

從主從複製到Group Replication

MySQL Group Replication 學習筆記

深入剖析 Group Replication核心的引擎特性

資源下載

關注公眾號：資料和雲（OraNews）回複關鍵字擷取

‘2017DTC’，2017DTC大會PPT

‘DBALIFE’，“DBA的一天”海報

‘DBA04’，DBA手記4經典篇章電子書

‘INTERNALS’，Oracle RAC PPT

‘122ARCH’，Oracle 12.2體繫結構圖

‘2017OOW’，Oracle OpenWorld資料

‘PRELECTION’，大講堂講師課程資料