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上並行操作。
具體實踐可以參考我之前的一篇文章：以Docker方式實現MySql 主從複製（實踐篇）
作者：crane-yuan 日期：2017-11-30