MySQL 複製與高可用水平擴展架構實戰
本文簡單介紹幾種複製方式複製在生產中解決的實際問題，MySQL 複製的配置流程和 MySQL 複製類型，不會深入到 MTBF、MTTR 平均故障間隔、平均修復時間等等以及 MMM 集羣架構、MHA 集羣架構等等產線實際應用的架構，也不會深入複製的原理，本文主要是帶讀者建立完整的 MySQL 複製的知識體系，後續會通過單獨的文章講解：
MySQL 複製工作原理（待補充）、MySQL 高可用架構與企業級實戰（待補充）。
1、什麼是複製
MySQL 的複製是構建大規模、高性能應用程序的基礎，稱爲 “水平擴展” 架構。生產環境通常爲服務器配置一個或多個備用數據庫以同步數據。
複製是將一臺服務器（即 MySQL 數據庫）的數據與其他服務器同步。
一個主數據庫的數據可以同步到多個備用數據庫，備用數據庫本身也可以配置爲另一個服務器的主數據庫。主數據庫和備用數據庫之間有許多不同的組合。
可以通過複製將讀取操作指向備用數據庫，以獲得更好的讀取擴展。
但是，對於寫操作，複製不適合擴展寫操作。在一個主數據庫和多個從數據庫的架構中，寫入操作將被多次執行。此時，整個系統的性能取決於寫入操作的最慢部分。
注：本文爲了追求正確 master 改爲 main，slave 改爲 secondary。
2、MySQL 數據庫的複製方式
MySQL 支持兩種複製方法：基於行的複製和基於語句的複製。
基於語句的複製（也稱爲邏輯複製）自 MySQL 3.23 以來就已經存在，基於行的複製是在 MySQL 5.1 中增加的新特性
兩種方法都通過在主數據庫上記錄二進制日誌並在備用數據庫上同步寫日誌來實現異步數據複製
這意味着備用數據庫上的數據可能在同一時間點與主數據庫不一致，主數據庫和備用數據庫之間的延遲無法保證。一些大型語句可能會導致備用數據庫延遲幾秒鐘、幾分鐘甚至幾小時。
3、複製可以解決的問題
3.1、數據分佈
MySQL 引入的基於行的複製後，比傳統的基於語句的複製模式帶來更大的帶寬壓力。這種情況對於複製操作可以隨時停止或開始，並在不同的地理位置（如兩地三中心）分發數據備份。
3.2、負載均衡
MySQL 複製可以將讀取操作分發到多個服務器，以優化讀取密集型應用程序。實施方便，可以通過簡單的代碼修改來實現負載平衡。
3.3、備份
對於備份，複製是一項重要的技術補充（但是不能代替 redo log、bin log 等）。
3.4、高可用性和故障切換
複製可以幫助應用程序避免 MySQL 單點故障（例如兩地三中心：生產中心、同城容災中心、異地容災中心），故障切換系統可以顯著減少停機時間。
3.5、MySQL 版本切換
使用更高版本的 MySQL 作爲備用數據庫，以確保在升級所有實例之前可以在備用數據庫中按預期執行查詢，最後逐步切換主庫。
這裏面一般使用的方法分爲 4 步，1、首先主備都使用低版本庫，2、切換備庫的時候，雙寫主備庫，查還是低版本，3、切換備庫的時候，雙寫主備庫，查使用高版本備庫，4、完全使用沒問題的主備高版本庫。
二、MySQL 複製的配置實戰
MySQL 複製實現非常簡單。基本步驟如下：
1、創建複製所需的帳戶和權限；
在 main（MASTER ）數據庫中創建一個用戶，並給予其適當的權限。備用數據庫 I/O 線程使用此用戶名連接到主數據庫，並讀取其二進制日誌。
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO repl@192.168.0.% IDENTIFIED BY 'password',;
2、要從主庫 main 複製數據副本，可以使用邏輯備份工具 mysqldump、mysqlpump 或物理備份工具克隆插件；（配置主庫和備庫一般是 DBA 的工作）
3、使用命令 CHANGE MASTER TO 建立複製關係（啓動複製）
4、使用命令 SHOW SLAVE STATUS 觀察複製狀態（當執行完 CHANGE MASTER TO ，需要通過 SHOW SLAVE STATUS 檢查複製是否正確）
MySQL 複製一般分爲以下幾種類型：異步複製、半同步複製、多源複製、延遲複製。
本文簡單介紹幾種複製方式，不會深入到 MTBF/(MTBF+MTTR)，平均故障間隔、平均修復時間以及 MMM 集羣架構、MHA 集羣架構等等產線實際應用的架構，也不會深入複製的原理，本文主要是帶讀者建立完整的 MySQL 複製的知識體系，後續會通過單獨的文章講解：
MySQL 複製工作原理（待補充）、MySQL 高可用架構與企業級實戰（待補充）。
1、異步複製（async replication）
在異步複製中，主庫 main 不關心從庫 secondary 是否接收二進制日誌，因此主庫 main 不依賴從庫 secondary 。您可以認爲 main 和 secondary 是兩個獨立工作的服務器，數據最終將通過二進制日誌保持一致。
異步複製性能最好，因爲對數據庫本身幾乎沒有開銷，除非主從延遲非常大，並且轉儲線程需要讀取大量二進制日誌文件。
如果企業對數據一致性的要求較低，則可以在發生故障時容忍數據丟失。推薦異步複製，它具有最好的性能（例如微博業務，雖然它對性能要求很高，但通常可以容忍數據丟失）。而核心交易業務系統通常最關心數據安全，如監控業務和報警系統。
2、半同步複製（semi-synchronous replication）
半同步複製分爲有損和無損，有損半同步一般沒有使用場景。半同步複製要求在主事務提交過程中至少有 N 個從庫 secondary 接收二進制日誌，這樣當主庫 main 停機時，至少有 N 臺從庫 secondary 中的數據是完整的。
無損半同步複製 WAIT ACK 發生在事務提交之前。即使從庫 secondary 沒有收到二進制日誌，主庫 main 也已關閉，由於異常尚未提交，因此數據本身對外界不可見，也不存在丟失的問題。
因此，對於任何有數據一致性要求的業務，如核心訂單業務、銀行、保險、證券等與資金密切相關的業務，必須使用無損半同步複製。通過這種方式，數據是安全和有保障的，並且即使發生故障，從庫 secondary 也擁有完整的數據副本。
3、多源複製（multisource replication）
異步複製與半同步複製都是一個主庫 main 都對應於 N 個從庫 secondary 。MySQL 還支持 N 個主機對應 1 個從庫。這種架構稱爲多源複製。
多源複製允許將不同 MySQL 實例上的數據同步到一個 MySQL 實例，便於在一個從庫 secondary 上進行一些統計查詢，例如常見的 OLAP 業務查詢。
延遲複製允許從庫 secondary 延遲接收的二進制日誌，爲了避免主服務器上的錯誤操作，它會立即同步到從庫 secondary ，導致數據完全丟失。
CHANGE MASTER TO master_delay = 10800例如，您可以設置延遲一天的待機機器，如果出現在線錯誤操作，如 DROP TABLE 和 DROP DATABASE，用戶可以獲得一天的快照，快速恢復數據。
對於金融行業來說，延遲複製是備份設計中必須考慮的一個體繫結構部分（博主就是使用多源複製 + 延遲複製 + 無損半同步複製的）。
本文簡單介紹幾種複製方式複製在生產中解決的實際問題，MySQL 複製的配置流程和 MySQL 複製類型，不會深入到 MTBF、MTTR 平均故障間隔、平均修復時間等等以及 MMM 集羣架構、MHA 集羣架構等等產線實際應用的架構，也不會深入複製的原理，本文主要是帶讀者建立完整的 MySQL 複製的知識體系，後續會通過單獨的文章講解：
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://www.toutiao.com/article/7168665367794057767/?log_from=c72ee289c4fff_1672795206869