MySQL 複製介紹

通過複製，可以將來自一個MySQL資料庫伺服器（主伺服器）的資料複製到一個或多個MySQL資料庫伺服器（從伺服器）。 預設情況下複製是非同步的; 從伺服器不需要一直連線以接收來自主站的更新。 根據配置，可以複製資料庫中的所有資料庫，選定資料庫甚至選定的表。

MySQL中複製的優點包括：

• 橫向擴充套件解決方案 - 將負載分散到多個從伺服器以提高效能。 在此環境中，所有寫入和更新都必須在主伺服器上進行。 然而，讀可能發生在一個或多個從伺服器身上。 這種模式可以提高寫入的效能（因為主伺服器專用於更新），同時顯著提高越來越多的從伺服器的讀取速度。
• 資料安全性 - 因為資料被複制到從伺服器，從伺服器可以暫停複製過程，所以可以在從伺服器上執行備份服務，而不會破壞相應的主服務資料。
• 分析 - 可以在主伺服器上建立實時資料，而資訊的分析可以在從伺服器上進行，而不會影響主伺服器的效能。
• 遠端資料分發 - 您可以使用複製為遠端伺服器建立本地資料副本，而無需永久訪問主伺服器資料。

MySQL 5.7支援不同的複製方法。 傳統的方法是基於主伺服器的二進位制日誌事件，並要求主伺服器和從伺服器的日誌檔案和日誌檔案中同步的位置。 基於全域性事務識別符號（GTIDs）的新方法是事務性的，因此並不需要日誌的檔案或日誌中同步的位置，從而大大簡化了許多常見的複製任務工作。 只要在主伺服器上提交的所有事務也被應用在從站上，使用GTIDs的複製就可以保證主伺服器和從伺服器之間的一致性。（注：本文只講解基於binlog方式的複製原理，關於GTIDs後期有時間再補充。）

MySQL 複製解決的問題

• 資料分佈（data distribution）
• 負載平衡（load balancing）
• 備份（backup）
• 高可用性和容錯行（high availability and failover）

MySQL 支援的複製型別

• 基於語句的複製。 在主伺服器上執行的 SQL 語句，在從伺服器上執行同樣的語句。否則，你必須要小心，以避免使用者對主伺服器上的表進行的更新與對伺服器上的表所進行的更新之間的衝突，配置：binlog_format = ‘STATEMENT’
• 基於行的複製。把改變的內容複製過去，而不是把命令在從伺服器上執行一遍，從 MySQL 5.0開始支援，配置：binlog_format = ‘ROW’
• 混合型別的複製。預設採用基於語句的複製，一旦發現基於語句的無法精確的複製時，就會採用基於行的複製,配置：binlog_format = ‘MIXED’

MySQL 複製是如何工作的（binlog方式）？

從高層來看，複製分成三步：
- master將改變記錄到二進位制日誌(binary log)中（這些記錄叫做二進位制日誌事件，binary log events）
- slave將master的binary log events拷貝到它的中繼日誌(relay log)
- slave重做中繼日誌中的事件，將改變反映它自己的資料

該過程的第一部分就是master記錄二進位制日誌。在每個事務更新資料完成之前，master在二日誌記錄這些改變。MySQL將事務序列的寫入二進位制日誌，即使事務中的語句都是交叉執行的。在事件寫入二進位制日誌完成後，master通知儲存引擎提交事務。

下一步就是slave將master的binary log拷貝到它自己的中繼日誌。首先，slave開始一個工作執行緒——I/O執行緒。I/O執行緒在master上開啟一個普通的連線，然後開始binlog dump process。Binlog dump process從master的二進位制日誌中讀取事件，如果已經跟上master，它會睡眠並等待master產生新的事件。I/O執行緒將這些事件寫入中繼日誌。

SQL slave thread處理該過程的最後一步。SQL執行緒從中繼日誌讀取事件，更新slave的資料，使其與master中的資料一致。只要該執行緒與I/O執行緒保持一致，中繼日誌通常會位於OS的快取中，所以中繼日誌的開銷很小。
此外，在master中也有一個工作執行緒：和其它MySQL的連線一樣，slave在master中開啟一個連線也會使得master開始一個執行緒。複製過程有一個很重要的限制——複製在slave上是序列化的，也就是說master上的並行更新操作不能在slave上並行操作。

作者：crane-yuan 日期：2017-11-30

參考文章