基礎篇

第1章　復制的概述

簡單來說，“復制”就是將來自一個MySQL Server（這里指master角色，即主庫）的數據變更，通過其邏輯的二進制日志（binlog）傳輸到其他的一個或多個MySQL Server（這里指slave角色，即從庫）中，其他MySQL Server通過應用（回放）這些邏輯的二進制日志來完成數據的同步。這些MySQL Server之間的邏輯關系，我們稱為“復制拓撲”（也可以稱為“復制架構”）。

默認情況下，復制是異步的，即主庫將二進制日志傳輸到從庫之后，并不關心從庫是否成功收到。從庫是否收到這些二進制日志，不影響主庫的任何讀/寫訪問；而從庫的復制線程也可以隨意暫停或停止，并不影響主庫的讀/寫訪問。通常，異步模式能夠發揮數據庫的最高性能，但數據安全性卻得不到很好的保證，如果對數據安全性的要求較高，可以考慮使用半同步復制。

另外，默認情況下，復制的數據是針對整個實例的（排除部分系統表），你可以根據自身需求選擇是否需要復制整個實例的數據，是只復制某些庫，還是只復制某些表的數據等。接下來將簡要介紹MySQL中復制拓撲的一些適用場景，以及與復制相關的概念。

1.1　適用場景

MySQL主從復制拓撲可用于如下場景：

1. 橫向擴展（Scale-Out）

橫向擴展是指在多個從庫之間進行讀負載均衡，以提高讀性能。在此擴展方案中，所有數據變更在主庫上執行，讀負載可以分攤到一個或者多個從庫上。可以把之前在主庫上的讀負載剝離出來，以承載更多的寫請求，另外，如果讀負載越來越大，可以通過擴展從庫來提高讀性能。

2. 數據安全性（Data Security）

數據安全性在很大程度上需要靠數據副本來保證。在這里，副本可以理解為我們通常所說的備份。在MySQL中，為了保證二進制日志的位置和數據的一致性，通常在執行備份時需要阻塞寫操作，防止因數據變更而造成備份過程中所獲取的二進制日志位置與數據不一致。

大多數時候，我們使用的MySQL主從復制拓撲是這樣的：一主N從、兩主N從（N大于或等于1）。其中，主庫提供讀與寫或者只寫服務，從庫提供只讀服務（多個從庫通常會提供讀負載均衡以分攤單個從庫的讀壓力）。而主庫通常只有一個（在有兩個主庫的復制拓撲中，另一個主庫通常用于提供快速的高可用切換），提供只讀服務的從庫通常有多個。因此，雖然在主庫上執行備份能夠盡可能保證備份數據的實時性（即擁有最新的數據），但是由于在備份過程中需要通過阻塞寫操作來保證數據的一致性，因此會嚴重影響應用的寫可用性。對于主庫來說，從庫有多個，所以如果在從庫上執行備份，對只讀應用的可用性影響就要小很多（從庫的復制機制本身也支持斷點續傳）。也就是說，在執行備份操作時，選擇使用從庫而不使用主庫是一個更好的替代方案，這樣可以盡量減少對主庫性能以及數據安全性的影響。

3. 分析（Analytics）

在主庫上運行OLTP（聯機事務處理）應用，而OLAP（聯機分析處理）應用可以在從庫上運行，避免在主庫上運行OLAP應用對主庫性能造成影響。

4. 遠程數據分發（Long-Distance Data Distribution）

可以使用復制特性為遠程站點（例如分公司或者分地域的應用中心）創建數據的本地副本，那些對數據實時性沒有要求的應用可以訪問本地副本，剩下的一小部分對實時性有要求的應用訪問主庫。遠程站點既可以作為災備中心，也可以用于實現跨地域訪問以分攤負載，以及實現就近訪問，加快訪問速度。

5. 在線滾動升級（Online Rolling Upgrade）

先升級從庫，然后執行主從切換，再升級主庫，從而實現數據庫應用不停機的在線升級（這里說的“不停機”并不是指應用完全無感知，在執行主從切換時，應用需要重新連接數據庫）。

6. 高可用切換（Failover）

當主庫發生故障時，可以把從庫提升為主庫，從而快速恢復服務。

1.2　數據同步方法

MySQL 5.7支持以下兩種數據同步方法（也可以稱為復制模式或復制方法）：

? 傳統復制：也可以稱為基于二進制日志文件和位置的復制，在從庫中配置復制時，要求指定從主庫中獲取的二進制日志文件（binlog file）和位置（binlog position），以便從庫中的復制線程啟動時，能夠以指定的二進制日志文件和位置為起點，持續讀取主庫中的二進制日志，并在從庫中應用，從而達到數據同步的目的。

? 基于GTID的復制（本書中為了表述上的方便，簡稱為GTID復制）：GTID（全局事務標識符）是新的事務性復制方法，利用GTID可以自動在主庫中尋找需要復制的二進制日志記錄，因此不需要關心日志文件或位置，極大地簡化了許多常見的復制任務。使用GTID復制可確保主庫和從庫之間的一致性。有關GTID的更多細節，詳見4.2節“GTID復制”。

1.3　數據同步類型

MySQL支持如下4種不同類型的數據同步：

? 異步復制：是最早出現的復制技術，MySQL內置支持，不需要額外安裝插件。其中，一個實例充當主庫，一個或多個其他實例充當從庫，與同步復制形成對比。

? 半同步復制：MySQL 5.7（從MySQL 5.5開始支持半同步復制）除內置了異步復制之外，還支持半同步復制。使用半同步復制時，主庫的會話在提交事務之前，會等待至少一個從庫返回收到二進制日志的ACK消息（確認接收，并將事務的事件記錄到從庫的中繼日志中）。

? 延遲復制：MySQL 5.7還支持延遲復制（從MySQL 5.6開始支持），使得從庫可以故意滯后于主庫至少一段指定的時間，以便在出現誤操作時，有時間對誤操作的數據進行補救。

? 同步復制：指的是需要保證寫操作完全同步到其他數據節點，而不僅僅是二進制日志被其他節點接收。例如NDB Cluster，它是一種集群架構，所有節點都可以進行讀/寫，而且每個節點上發生的寫操作都會實時同步到其他節點。對于需要同步復制的場景，可以使用NDB Cluster，或者其他類似的開源解決方案（虛擬同步，非完全同步），例如Percona XtraDB Cluster（PXC）、MariaDB Galera Cluster（MGC）、MySQL Group Replication（MGR）。

1.4　復制格式

MySQL支持兩種二進制日志格式（二進制日志記錄的是數據變更的邏輯）：一種是記錄語句原始文本（即statement格式，語句文本按原樣記錄到二進制日志），另一種是記錄數據的逐行變更（即row格式，將一個語句記錄到二進制日志中，可能產生多行數據變更記錄）。就具體的復制格式而言，可以分為三種，由系統變量binlog_format進行設置，有效值為：statement（對應下文中的SBR）、row（對應下文中的RBR）、mixed（mixed格式，混合使用statement和row格式，對應下文中的MBR）。這三種格式的詳情如下：

? 基于statement的復制（Statement Based Replication，SBR）：當系統變量binlog_format設置為statement時表示使用SBR。SBR復制的是整個SQL語句的原始文本，日志量較小，但容易出現主從庫數據不一致。對于SBR，當執行的某個語句被判定為不安全時，是否允許其執行還取決于事務的隔離級別。

? 基于row的復制（Row Based Replication，RBR）：當系統變量binlog_format設置為row時表示使用RBR。RBR復制的是發生更改的數據行的實際記錄（原始語句會被轉換為發生變更的行數據記錄），日志量較大，但可以保證主從庫數據的一致性。

? 混合復制（Mixed Based Replication，MBR）：系統變量binlog_format設置為mixed時表示使用MBR。MBR實際上是由MySQL自行判斷的，即在不影響數據一致性的情況下，使用SBR；如果可能影響數據一致性，則自動轉換為RBR。

提示：本章中復制相關的概念較多，容易混淆，這里做一個總結。MySQL中的復制，按照數據同步方法劃分，可分為傳統復制和GTID復制；按照數據同步類型劃分，可分為異步復制、半同步復制、延遲復制和同步復制；按照復制格式劃分，可分為基于statement的復制（SBR）、基于row的復制（RBR）和混合復制（MBR）。

有關復制的格式的更多信息，詳見第3章“復制格式詳解”。