MySQL 主從復制：一舉三得的架構紅利

MySQL 原生支援單向異步復制：主庫寫入二進制日志，從庫透過 I/O 線程拉取、SQL 線程重放，實現數據同步。這一機制不僅是高可用基石，更能為業務帶來負載均衡、異地備份、高可用三大實質紅利。

紅利一：讀寫分離實現負載均衡

將寫操作（INSERT/UPDATE/DELETE）路由至主庫，讀操作（SELECT）分流至一或多個從庫，顯著降低主庫壓力、縮短響應時間。兩種常見架構：

• 嚴格讀寫分離： 主庫僅寫，從庫群僅讀。適合「寫少讀極多」場景（如基金淨值查詢、商品瀏覽）。
• 主從共担讀寫： 主庫寫+部分讀，從庫讀；主庫忙時自動分流讀請求。適合讀寫均衡、容忍秒級延遲的場景。

關鍵權衡：同步延遲 vs. 一致性要求。 金融交易、庫存扣減需強一致，必須走主庫或採用半同步復制（rpl_semi_sync_master=ON）；報表、推薦、搜尋可容忍毫秒~秒級延遲，充分發揮從庫讀擴展價值。

紅利二：異地備份，災難恢復零距離

傳統本地備份佔用主庫資源、且無法抵禦機房級災難。主從復制天然實現異地熱備：

• 備份操作在從庫執行（mysqldump、xtrabackup、快照），完全不影響主庫業務。
• 從庫數據即最新副本，RPO（數據丟失量）僅等於復制延遲，RTO（恢復時間）極短。

兩大前置條件：

1. 同步間隔 ≤ 備份週期： 確保最近數據已同步到從庫再備份。
2. 從庫磁碟 ≥ 主庫 2×： 既要存全量數據，又要留備份空間、臨時文件、二進制日志餘量。

紅利三：秒級故障切換，業務零感知

主庫故障時，將從庫提升為新主庫，實現服務連續性。兩種切換策略：

• 只讀降級： 新主庫暫時只提供查詢，凍結寫入，待舊主庫修復後再雙主同步。適合極高數據安全要求（如銀行核心）。
• 全功能切換： 新主庫即刻承擔讀寫，但必須確保權限、參數、監控、備份策略與原主庫完全一致，否則留下安全隱患。

生產環境建議搭配 MHA、Orchestrator、GTID 自動化故障轉移工具，實現「檢測→切換→通知」全流程無人值守。

避坑指南：單向復制鐵律

嚴禁在從庫手動寫入數據！ 從庫唯讀（read_only=ON、super_read_only=ON），任何直接寫入都會導致主從數據分歧，甚至複製中斷。應用層路由邏輯需嚴格區分讀寫請求，防止誤路由。

總結

MySQL 主從復制以極低成本換取：讀擴展、異地容災、高可用 三重保障。關鍵在於：根據業務一致性要求選擇同步模式、從庫規格預留備份冗餘、自動化故障轉移落地、嚴守從庫唯讀原則。把這四點做到位，復制就是你架構中最可靠的杠桿。