1. 複製切換

1.1. 複製是高可用性的基礎

1.1.1. 總是保留一份持續更新的副本數據，會讓災難恢復更簡單

1.2. “切換副本”（promoting a replica）和“故障切換”（failing over）是同義詞

1.2.1. 意味著源伺服器不再接收寫入，並將副本提升為新的源伺服器

1.3. 計劃內切換

1.3.1. 常見原因

1.3.1.1. 安全補丁

1.3.1.2. 內核更新

1.3.1.3. 一些配置選項更改後需要重新啟動才能生效

1.3.2. 步驟

1.3.2.1. 確定將哪個副本切換為新的源

1.3.2.1.1. 一個包含所有數據的副本

1.3.2.2. 檢查延時，確保延時在秒級別

1.3.2.3. 通過設置super_read_only停止數據寫入源伺服器

1.3.2.4. 等待副本與目標完全同步

1.3.2.4.1. 通過比較GTID來確定

1.3.2.5. 在目標（需要切換為源的副本）上取消read_only設置

1.3.2.6. 將應用流量切換到目標上

1.3.2.7. 將所有副本重新指向新的源，包括剛剛被降級為副本的伺服器

1.3.2.7.1. 配置了GTID和AUTO_POSITION=1

1.4. 計劃外切換

1.4.1. 只要時間夠長，每個系統都會因軟體或硬體而出現故障

1.4.2. 當故障發生在承擔寫入的源伺服器上時，會對用戶體驗產生重大影響

1.4.3. 這時候不再存在一個實時運行的源伺服器了

1.4.4. 步驟

1.4.4.1. 確定需要切換的副本

1.4.4.1.1. 擇數據最完整的副本

1.4.4.2. 在目標上關閉read_only設置

1.4.4.3. 將應用流量切換到目標上

1.4.4.4. 將所有副本重新指向新源（目標伺服器），包括恢復後的原來提供服務的源伺服器

1.4.4.4.1. 切換前的源伺服器再次啟動時，需要預設啟用super_read_only

1.4.4.4.1.1. 防止任何意外的寫入

1.5. 切換時的權衡

1.5.1. 很難知道切換後的目標（新的源伺服器）可能丟失了多少數據

1.5.2. 有時不進行故障切換可能是更好的策略

1.5.3. 等待恢復的好處不會丟失任何數據，並且所有副本將繼續從中斷的地方工作

2. 複製拓撲

2.1. 幾乎任何一個源和副本都可以配置MySQL複製

2.2. 主動/被動模式

2.2.1. 應用將所有讀取和寫入都指向單個源伺服器

2.2.2. 不用擔心複製延遲的問題

2.2.3. 可以防止應用程式不接受讀取延遲數據的問題

2.2.4. 配置

2.2.4.1. 應該儘量讓源和副本在CPU、記憶體等方面具有相同的配置

2.2.4.2. 副本上使用相同的硬體和軟體配置就可以確保能夠支持切換之前的應用流量容量和吞吐量

2.2.5. 冗餘

2.2.5.1. 在物理硬體環境中，推薦使用至少三台伺服器的n+2冗餘

2.2.5.2. 如果數據足夠少，或者可以輕鬆複製數據，也可以使用至少兩台伺服器的n+1冗餘，否則還是建議n+2

2.2.5.3. 如果無法在源伺服器上進行備份操作，可以使用其中一個副本作為備份伺服器

2.2.6. 註意事項

2.2.6.1. 實際上是將讀擴展綁定到單台伺服器的容量上

2.2.6.2. 如果達到讀擴展上限

2.2.6.2.1. 則必須演進到更複雜的拓撲

2.2.6.2.1.1. 主動/只讀池配置

2.2.6.2.2. 否則就不得不利用分片來減少源上的讀取壓力

2.3. 主動/只讀池配置

2.3.1. 將所有寫入指向源伺服器

2.3.2. 根據應用程式的需要，讀取則可以被髮送到源伺服器或只讀池

2.3.3. 只讀池可以實現讀取密集型應用程式的讀水平擴展

2.3.4. 由於源上的複製請求，水平擴展能力會受到限制

2.3.5. 配置

2.3.5.1. 如果隨著時間的推移，只讀池在持續增長，則可以讓副本用不同的硬體配置來優化成本

2.3.5.2. 將流量進行加權，運行在更好的硬體配置的副本上可以承擔更多的流量

2.3.6. 冗餘

2.3.6.1. 應滿足先前提出的要求，還需要至少一臺伺服器可以充當故障切換的目標

2.3.7. 註意事項

2.3.7.1. 只讀池的大小會決定管理的複雜度，以及何時應該考慮自動化

2.4. 不推薦的拓撲架構

2.4.1. 雙源主動-主動架構

2.4.1.1. 雙向複製

2.4.1.2. 涉及兩台伺服器，每台伺服器都配置為源和另一臺的副本

2.4.1.3. 一對協同源

2.4.2. 雙源主動-被動模式

2.4.2.1. 主動-主動模式下的雙源伺服器有一個變種

2.4.2.2. 其中一臺伺服器是只讀的“被動”伺服器

2.4.3. 帶有副本的雙源模式

2.4.3.1. 兩個可寫的源只會帶來麻煩

2.4.4. 環形複製

2.4.4.1. 具有三個或更多個源，其中每台伺服器都在環中，它之前的伺服器是它的副本，它之後的伺服器作為它的源

2.4.4.2. 迴圈複製

2.4.5. 多源複製

3. 複製管理和維護

3.1. 在數據量很小而且寫入負載一致的時候，通常不太需要經常查看複製延遲或者複製中斷相關的問題

3.2. 複製監控

3.2.1. 複製同時需要源和副本上的磁碟空間

3.2.2. 監控複製的狀態和錯誤

3.2.2.1. 如果複製線程沒有正常運行，那麼可以查看報錯信息，以確定下一步應該做什麼來修複錯誤

3.2.3. 延遲複製的實際延遲

3.2.3.1. 太長的延遲可能會使其使用起來更加耗時

3.3. 觀測複製延遲

3.3.1. 副本與源之間的複製延遲是多少

3.3.2. 最好的解決方案是心跳記錄，它需要在源上每秒更新一次時間戳

3.3.2.1. 創建了一個方便的時間戳，展示副本中的數據在什麼時間點是最新的

3.3.2.2. Percona Toolkit中包含的pt-heartbeat腳本是當前最流行的複製心跳實現方案

3.3.2.3. 二進位日誌中的複製心跳記錄可用於許多目的

3.4. 確定副本數據的一致性

3.4.1. 副本始終是其源的精確複製減去其複製延遲的部分

3.4.2. 副本與源不一致的原因

3.4.2.1. 意外寫入副本

3.4.2.2. 使用雙源複製，雙方都寫入了數據

3.4.2.3. 非確定性語句和基於語句的複製

3.4.2.4. 當運行在弱持久化模式時MySQL崩潰

3.4.2.5. MySQL中的Bug

3.4.3. 建議遵循的規則或配置

3.4.3.1. 在副本上，始終啟用super_read_only

3.4.3.1.1. 使用read_only可以防止沒有SUPER許可權的用戶寫入，但這不會阻止DBA在沒有意識到他們在副本上的情況下運行DELETE或ALTER

3.4.3.1.2. super_read_only設置只允許複製寫入，是運行副本的最安全方式

3.4.3.2. 使用基於行的複製或確定性語句

3.4.3.2.1. 基於行的複製是複製數據的最一致的方式

3.4.3.2.2. 使用ORDER BY，使行順序具有確定性

3.4.3.3. 不要嘗試同時寫入複製拓撲中的多台伺服器

3.4.3.3.1. 最實用的複製拓撲是使用一個源，執行所有寫入操作，以及一個或多個副本，可選擇地執行讀取操作

4. 複製問題和解決方案

4.1. 使用副本擴展讀取操作，使用分片技術擴展寫入操作

4.2. 源端二進位日誌損壞

4.2.1. 如果源上的二進位日誌已被損壞，那麼別無選擇，只能重建副本

4.3. 非唯一的伺服器ID

4.3.1. 如果你不小心配置了具有相同伺服器ID的兩個副本，不仔細觀察的話，它們似乎可以正常工作

4.3.2. 在源伺服器上，任何時候都只能看到兩個副本中的一個

4.3.3. 解決此問題的唯一方法是在設置副本時要小心

4.3.3.1. 創建副本到伺服器ID映射的規範列表很有幫助

4.3.3.2. 如果副本完全位於一個子網中，則可以使用每台機器IP地址的最後一個八位位元組來作為唯一ID

4.4. 未配置伺服器ID

4.4.1. MySQL將顯示為使用CHANGEREPLICATION SOURCE TO配置了複製，但不會允許啟動副本

4.4.2. 你可能會從SELECT＠＠server_id中獲得一個值，但這隻是一個預設值

4.4.2.1. 必須顯式設置該值

4.5. 臨時表丟失

4.5.1. 臨時表在某些場景中使用起來很方便，但不幸的是，它們與基於語句的複製不相容

4.5.2. 如果副本崩潰或將其關閉，則副本線程正在使用的任何臨時表都會消失

4.5.3. 當重新啟動副本時，引用丟失的臨時表的任何相關語句都將失敗

4.5.4. 最好的方法是使用基於行的複製

4.5.4.1. 其次是統一命名臨時表（例如，以temporary_為首碼），然後使用複製規則完全跳過複製臨時表

4.6. 沒有複製所有變更

4.6.1. 如果誤用SET SQL_LOG_BIN=0或不瞭解複製過濾規則，可能會導致副本不會執行源上發生的某些變更

4.7. 複製延遲過大

4.7.1. 多線程複製

4.7.2. 使用分片技術

4.7.2.1. 使用分片技術將寫入分散到多個源也是一種非常有效的策略

4.7.3. 臨時降低持久化要求

4.7.3.1. 如果複製延遲主要是由於寫入操作導致的，則可以臨時設置sync_binlog=0和innodb_flush_log_at_trx_commit=0以提高複製速度

4.7.3.2. 最好只在副本上執行此操作，如果此副本也用於執行備份操作，則更改這些設置可能會使你無法從備份中恢復完整的數據

4.7.3.3. 一種可能的策略是監控SHOW REPLICA STATUS命令中的Seconds_behind_source值，當它超過某個閾值時

4.7.3.3.1. 驗證是否啟用了super_read_only，以確保伺服器是不可寫副本

4.7.3.3.2. 更改sync_binlog和innodb_flush_log_at_trx_commit的配置以減少寫操作

4.7.3.3.3. 定期檢查SHOW REPLICA STATUS以獲取Seconds_behind_source的值

4.7.3.3.4. 當延遲低於可接受的閾值時，將持久性相關參數恢復到正常值

4.8. 來自源伺服器的超大數據包

4.8.1. 當源伺服器的max_allowed_packet大小與副本不匹配時，可能會出現另一個難以跟蹤的複製問題

4.8.2. 源伺服器可以記錄副本認為過大的數據包，當副本檢索該二進位日誌事件時，它可能會遇到各種問題，其中包括無休止的錯誤迴圈、重試或中繼日誌中的損壞

4.9. 磁碟空間耗盡

4.9.1. 當源伺服器執行大量LOAD DATA INFILE語句併在副本上啟用log_replica_updates時

4.9.2. 複製延遲越大，用於已從源端獲取但尚未執行的中繼日誌占用的磁碟空間就越多

4.9.3. 可以通過監控磁碟使用情況並設置relay_log_space參數來防止這些錯誤出現

4.10. 複製的限制

4.10.1. 因為MySQL自身固有的一些限制，無論有沒有出現明確的報錯，MySQL複製都可能失敗或不同步

4.10.2. 伺服器中的bug

4.10.2.1. MySQL伺服器的許多大版本歷史上都有複製方面的bug

4.10.2.1.1. 尤其是在大版本的第一個版本中