1. 概述

1.1. 複製解決的基本問題是讓一臺伺服器的數據與其他伺服器保持同步

1.2. 在源伺服器（source server）上，任何數據修改和數據結構變更的事件（event）都會被寫入日誌文件中

1.3. 副本伺服器從源伺服器上的日誌文件中讀取這些事件併在本地重放執行

1.4. 一個非同步處理的過程

1.4.1. 不能保證副本伺服器上的數據是最新的

1.4.2. 複製延遲（副本數據和最新數據之間的時間差）也並沒有上限

1.5. MySQL複製是其內置的一把“瑞士軍刀”

1.6. MySQL的複製基本上是向後相容的

1.6.1. 新版本的伺服器可以作為老版本的伺服器的副本

1.6.2. 老版本的伺服器作為新版本的伺服器的副本通常是不可行的

1.7. 通過複製可以將讀操作指向副本來獲得更好的讀擴展性

1.7.1. 並不適合通過複製來擴展寫操作

1.8. 在一主庫多副本庫的架構中，寫操作會被執行多次，這時候整個系統的性能取決於寫入最慢的那部分

1.9. 在複製架構中，讀取和重放日誌事件是解耦的

1.9.1. 允許讀取日誌和重放日誌非同步進行

1.9.2. I/O線程和SQL線程都是可以獨立運行的

2. 用途

2.1. 數據分發

2.1.1. 不會對帶寬造成很大的壓力

2.1.2. 基於行的複製會比傳統的基於語句的複製模式的帶寬壓力更大

2.1.3. 如果為了保持很低的複製延遲，最好有一個穩定的、低延遲連接

2.2. 讀流量擴展

2.2.1. 可以將讀操作分佈到多台伺服器上，實現對讀密集型應用的優化

2.2.2. 對於小規模的應用，可以簡單地對機器名做硬編碼或使用DNS輪詢

2.3. 備份

2.3.1. 一項有助於備份的有價值的技術，但副本不是備份，也不能夠取代備份

2.4. 分析與報告

2.4.1. 為報告/分析（線上分析處理，OLAP）查詢使用專用的副本是一項很好的策略

2.4.2. 可以很好地隔離此類查詢產生的壓力，以避免對滿足外部客戶需求的線上業務產生影響

2.5. 高可用性和故障切換

2.5.1. 有助於避免MySQL成為應用程式中的單點故障

2.5.2. 一個包含複製的設計良好的故障切換系統能夠顯著地縮短宕機時間

2.6. MySQL升級測試

2.6.1. 先使用一個更高版本的MySQL作為副本，確保查詢能夠在此副本上按照預期執行，再升級所有的實例

3. 步驟

3.1. 源端把數據更改記錄到二進位日誌中，稱之為“二進位日誌事件”（binary log events）

3.2. 副本將源上的日誌複製到自己的中繼日誌中

3.3. 副本讀取中繼日誌中的事件，將其重放到副本數據之上

4. 原理

4.1. 複製格式

4.1.1. 基於語句的

4.1.1.1. 通過記錄所有在源端執行的數據變更語句來實現的

4.1.1.2. 簡單且緊湊

4.1.1.3. 一條更新了大量數據的SQL語句，在二進位日誌中可能僅僅需要幾十位元組存儲

4.1.1.4. “不確定性”的SQL語句問題

4.1.1.4.1. 如果在源和副本上，記錄的排序不同，這條SQL語句在源和副本上刪除的100條記錄就會不同，這將導致數據不一致

4.1.1.5. 除非某些場景下明確需要臨時使用基於語句的複製

4.1.2. 基於行的

4.1.2.1. 每條被改變的記錄都會作為事件被寫入二進位日誌

4.1.2.2. 讓二進位日誌的大小發生巨大的增長

4.1.2.3. 建議堅持使用基於行的複製

4.1.2.3.1. 提供了最安全的數據複製方法

4.1.3. 混合模式

4.1.3.1. the mixed method

4.1.3.2. 事件的寫入，預設使用基於語句的格式，僅在需要時才切換到基於行的格式

4.1.3.3. 在寫入每個事件時會有很多的判斷條件，以確定使用哪種格式，而這也會導致二進位日誌中出現不可預測的事件

4.1.3.4. 不使用

4.2. 全局事務標識符

4.2.1. GTID

4.2.2. 使用GTID，源伺服器提交的每個事務都被分配一個唯一標識符

4.2.3. 由server_uuid和一個遞增的事務編號組成的

4.2.4. 當事務被寫入二進位日誌時，GTID也隨之被寫入

4.2.4.1. 當SQL線程提交事務時，它也會將GTID標記為執行完成

4.2.5. GTID解決了運行MySQL複製的一個令人痛苦的問題：處理日誌文件和位置

4.2.6. 強烈建議在資料庫中啟用GTID

4.3. 崩潰後的複製安全

4.3.1. innodb_flush_log_at_trx_commit=1

4.3.1.1. 可以保障每個事務日誌都被同步地寫到磁碟

4.3.1.2. 這是一個符合ACID要求的配置，將最大限度地保護你的數據

4.3.1.3. 二進位日誌事件首先被提交，然後事務將被提交並寫入磁碟

4.3.1.4. 此參數設置為1將增加磁碟寫入操作的頻次，同時確保數據的持久性

4.3.2. sync_binlog=1

4.3.2.1. 控制MySQL將二進位日誌數據同步到磁碟的頻率

4.3.2.2. 設置為1意味著在每次事務執行的時候都會把二進位日誌同步寫入磁碟

4.3.2.3. 可以防止在伺服器崩潰時丟失事務

4.3.2.4. 會增加磁碟寫入量

4.3.3. relay_log_info_repository=TABLE

4.3.3.1. 信息將被轉移到MySQL本身的InnoDB表中，允許複製更新同一事務中的事務和中繼日誌信息

4.3.3.2. 會在一個原子操作中完成，並有助於崩潰恢復

4.3.4. relay_log_recovery=ON

4.3.4.1. 使得副本伺服器在檢測到崩潰時會丟棄所有本地中繼日誌，並從源伺服器中獲取丟失的數據

4.3.4.2. 確保了在崩潰中發生的磁碟上的任何損壞或不完整的中繼日誌都是可恢復的

4.3.4.3. 不再需要配置sync_relay_log

4.3.4.3.1. 因為在發生崩潰時，中繼日誌將被刪除，也就無須花費額外的操作將它們同步到磁碟

4.4. 延遲複製

4.4.1. 某些副本有一些延遲反而是有好處的

4.4.2. 可以讓副本中的數據保持線上並且持續運行，但同時落後於源資料庫數小時或者數天

4.4.3. 配置語句是CHANGEREPLICATION SOURCE TO，配置選項為SOURCE_DELAY

4.4.4. 場景

4.4.4.1. 刪除了一個表

4.4.4.1.1. 從備份中恢復可能需要幾個小時

4.4.4.1.2. 如果使用了延遲複製的副本，則可以找到DROP TABLE語句對應的GTID，使副本伺服器的複製運行到表被刪除之前的時間點，這會大大減少修複時間

4.5. 多線程複製

4.5.1. 在副本端運行多個SQL線程，從而加快本地中繼日誌的應用

4.5.2. 兩種模式

4.5.2.1. DATABASE模式

4.5.2.1.1. 使用多線程更新不同的資料庫

4.5.2.1.2. 但不會有兩個線程同時更新同一個資料庫

4.5.2.1.3. 將數據分佈在MySQL的多個資料庫中，則可以同時並且一致地更新它們，這種模式非常有效

4.5.2.2. LOGICAL_CLOCK模式

4.5.2.2.1. 允許對同一個資料庫進行並行更新，只要它們都是同一個二進位日誌組提交的一部分

4.5.2.2.2. 人工延遲的配置參數

4.5.2.2.2.1. binlog_group_commit_sync_delay（以微秒為單位的延遲）

4.5.2.2.2.2. binlog_group_commit_sync_no_delay_count（決定中止等待之前要等待的事務數）

4.5.2.2.2.3. 確保你的副本配置了參數replica_preserve_commit_order，這樣就不會出現無序提交的問題

4.6. 半同步複製

4.6.1. 在啟用半同步複製後，源在完成每個事務提交時，都需要確保事務至少被一個副本所接收

4.6.2. 需要確認副本已收到併成功將其寫入自己的中繼日誌（但不一定應用到本地數據）

4.6.3. 如果在一定時間範圍內沒有副本確認事務，MySQL將恢復到標準的非同步複製模式

4.6.4. 半同步複製不是一種防止數據丟失的方法，而是可以讓你擁有更具彈性的故障切換的更大工具集的一部分

4.6.5. 建議不要依賴該功能來保證數據完整性

4.7. 複製過濾器

4.7.1. 可以讓副本僅複製一部分數據

4.7.2. 複製過濾器是一顆定時炸彈

4.7.3. 從源上的二進位日誌中過濾事件

4.7.3.1. binlog_do_db

4.7.3.2. binlog_ignore_db

4.7.3.3. 不僅有可能破壞複製，還會使從備份中進行時間點恢復變得不可能

4.7.3.3.1. 在大多數情況下都不應該使用它們

4.7.4. 從副本上的中繼日誌中過濾事件

4.7.4.1. replication_*選項在SQL線程從中繼日誌中讀取事件時過濾事件