作者：徐良，現任中國移動智慧家庭運營中心數據庫高級經理，多年數據庫運維優化經驗，歷任華為、一線互聯網公司高級 DBA。目前主要負責中移智家基于規模的價值運營場景下數據庫穩定性、容災優化、異地多活等相關工作。
愛可生開源社區出品，原創內容未經授權不得隨意使用，轉載請聯系小編并注明來源。
本文約 2800 字，預計閱讀需要 7 分鐘。
1背景介紹
在云網融合大數據時代，數據已經成為重要的生產要素。特別是棱鏡門、永恒之藍、汶川大地震這類造成大規模數據丟失和泄漏的人為或自然災害事件發生后，中國相繼出臺了一系列的法律法規，對各組織機構的數據安全保護條件進行限定，如 2016 年頒布的《中華人民共和國網絡安全法》、 2021 年全國人民代表大會通過的《數據安全法》等。
當發生災難時，容災備份能夠確保數據不丟失。要實現應用的容災，一個關鍵就是通過數據庫的實時同步和復制，在 A 地出現機房故障和問題的時候可以平滑快速的遷移到 B 地。雖然這種遠程數據復制和同步存在一定的延遲，但是基本可以滿足業務連續性的需求。
2容災的基礎概述容災的定義
容災是指當數據中心發生各種未知災難的時候，確保數據不丟失或少丟失，同時 IT 業務系統能夠不間斷運行或快速切換恢復。
災難的衡量指標
評估一個災備系統可靠性的兩個重要指標是 RTO 與 RPO。
RTO (Recovery Time Objective)恢復時間目標。RTO 是指災難發生后，從系統宕機導致業務停頓之刻開始，到系統恢復至可以支持業務部門運作，業務恢復運營之時，此兩點之間的時間。RTO 可簡單地描述為企業能容忍的恢復時間。
RPO (Recovery Point Objective)恢復點目標。RPO 是指災難發生后，容災系統能把數據恢復到災難發生前時間點的數據，它是衡量企業在災難發生后會丟失多少生產數據的指標。RPO可簡單地描述為企業能容忍的最大數據丟失量。
RTO 針對的是服務時間的丟失，RPO 針對的是數據的丟失，兩者是衡量容災系統的兩個主要指標，但它們沒有必然的關聯性。
容災的等級分類
2007 年 11 月 1 日開始正式實施的國家標準 (GB/T 20988-2007) 是我國災難備份與恢復行業的第一個國家標準。
| 等級 | 說明 |
|---|---|
| 第 1 級 | 基本級。備份介質場外存，安全保障、 定期驗證。 |
| 第 2 級 | 備份場地支持。網絡和業務處理系統可在預定時間內調配到備份中心。 |
| 第 3 級 | 電子傳輸和部分設備支持。災備中心配備部分業務處理和網絡設備，具備部分通訊鏈路。 |
| 第 4 級 | 電子傳輸和完整設備支持。數據定時批量傳送，網絡/系統始終就緒。溫備中心模式。 |
| 第 5 級 | 實時數據傳輸及完整設備支持。采用遠程復制技術，實現數據實時復制，網絡具備自動或集中切換能力，業務處理系統就緒或運行中。 |
| 第 6 級 | 數據零丟失和遠程集群支持。數據實時備份，零丟失，系統 /應用遠程集群，可自動切換，用戶同時接入主備中心。 |
災難與 RTO、RPO 的關系
| 災難恢復能力等級 | RTO | RPO |
|---|---|---|
| 1 | 2 天以上 | 1 天至 7 天 |
| 2 | 24 小時以后 | 1 天至 7 天 |
| 3 | 12 小時以上 | 數小時至 1 小時 |
| 4 | 數小時至 2 天 | 數小時至 1 小時 |
| 5 | 數分鐘至 2 天 | 0 至 30 分鐘 |
| 6 | 數分鐘 | 0 |
兩地三中心容災
兩地三中心能夠組合本地高可用，同城災備中心，異地災備中心，提高可用性，提升業務連續性，重點業務多采用“兩地三中心”（即生產數據中心、同城災備中心、異地災備中心）建設方案。這種模式下，多個數據中心是主備關系，針對災難的響應與切換周期根據異常情況靈活處理，能夠實現更優的 RTO 與 RPO 整體目標。
3MySQL 常見的主從形式
MySQL 本身就自帶有主從復制的功能，解決了幾個關鍵的問題：數據一致性、檢查點機制、可靠網絡傳輸等，可以幫助我們實現高可用切換和讀寫分離。
一主一從
一主一從能夠提供備庫，主庫故障后可以進行故障切換，避免數據丟失。
一主多從
一主多從常見的主從架構，使用起來簡單有效，不僅可以實現 HA，而且還能讀寫分離，進而提升集群的并發能力。
多主一從
多主一從可以將多個 MySQL 數據庫備份到一臺存儲性能比較好的服務器上，方便統一分析處理。
雙主復制
雙主復制，也就是互做主從復制，每個 master 既是 master，又是另外一臺服務器的 slave。這樣任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。同一時刻可以只有一個是主，另外一個是備，實例主動維護進行主從切換的時候無需進行特別的配置，秒級切換方便日常升級維護。
級聯復制
級聯復制模式下，部分 slave 的數據同步不連接主節點，而是連接從節點。主節點有太多的從節點，就會損耗一部分性能用于 replication ，這個時候可以讓 3~5 個從節點連接主節點，其它從節點作為二級或者三級與從節點連接，這樣不僅可以緩解主節點的壓力，并且對數據一致性沒有負面影響。
4兩地三中心 MySQL 主從復制MySQL 常見高可用方案優劣
對比目前主流的數據庫高可用方案，都有各自的優勢和劣勢，但在支持異地容災方面都不夠簡單易用：
| 高可用方案 | 優勢 | 劣勢 |
|---|---|---|
| 主從 + Keepalived | 部署簡單，沒有主實例宕機后選主的問題。 | 一主多從在切換之后，其他從實例需要重新配置連接新主。 |
| MHA | 支持一主多從、主服務崩潰時不會導致數據不一致。 | SSH 存在安全隱患，官方不再維護。 |
| 組復制 MGR | 無延遲，數據強一致性。 | 強依賴網絡，只能用在 GTID 模式下，大事務和 DDL 操作有阻塞風險。 |
| MySQL InnoDB Cluster | 彌補組復制無法提供具有自動化故障轉移功能的中間件。 | 組件多，成熟案例少。 |
| Orchestrator | 支持一主多從，解決了管理節點的單點問題，支持命令行和 Web 界面管理復制。 | 功能復雜，不方便集成進自有系統。 |
MySQL 主從初始化消息
通過抓取消息和分析代碼，發現 MySQL 從庫和主庫建立同步通道過程中，分別進行網絡連接建立、授權，實例唯一性、時鐘、字符集、binlog 配置校驗等工作。其中實例唯一性校驗過程從庫會獲取主庫的 server id。
MySQL binlog 日志結構
MySQL 的主從復制是基于 binlog 文件，而 binlog 文件是由多個 binlog event 構成，binlog event 的整體結構由 head+data+footer 三部分組成。head 包含產生 event 的數據庫實例 server id，在主從復制作為區分 event 是否為自己實例生成的重要依據。
之前通過主從初始化消息能夠獲取主從管道對端主庫的 server id，此時和從庫從管道內接受的 event 的 server id 進行對比，能夠識別該 event 是否是當前對端主庫產生的。
兩地三中心 MySQL 主從方案 1
兩地三中心建設相對容易，日常的演練和數據回流等配置比較繁瑣，容易出錯。本方案通過機房內建立 MySQL 主主復制，此時主從切換無需繁瑣的命令，只需要設置 read_only；同城機房間也是建立主主復制，方便容災演練回切，無需復雜的配置。同理，與兩地三中心 MySQL 也建立主主復制，方便演練和回切。該方案使用原生的 MySQL 復制，成熟度高；未過多引入第三方組件，具備規?；\維潛力。但原生的 MySQL 主從在多條鏈路存在主主復制時，會出現復制回路問題，導致數據沖突和不一致。
兩地三中心 MySQL 主從方案 2
為解決復制回路問題，在主機房邊界節點實例上，本方案使用上文中根據對端主庫 server id 判斷是否和 event 的 server id 相同，對 IDC1 邊界 MySQL 復制邏輯進行限制，只同步管道內臨近主產生的 binlog 日志，級聯主日志丟棄，1 個同步管道只同步單臺 master 日志，解決回路問題。其他節點無需開啟這個功能。
邊界節點 MySQL 復制邏輯代碼補丁
本補丁基于社區版 MySQL 5.7.40 升級，修改 sys_vars.cc 文件，增加 replicate_server_mode 配置項（默認為 0），兼容原有復制模式，配置為 1 時主從同步僅同步管道內對端主產生的 binlog event。
修改 log_event.cc 文件的 Log_event::do_shall_skip 函數，判斷當前 event 的 server_id 和本通道對端主庫 master 的 server_id 不相同時忽略，僅同步對端主庫產生的 event，避免多通道主主時數據回路的問題。
5總結
該 MySQL 數據同步方案優化了 MySQL 本身的日志同步機制，引入多通道主主復制技術，降低了機房容災演練和回切時數據同步關系調整帶的復雜性；每個通道僅同步臨近主庫 binlog event，解決了數據回路問題，支撐重點業務兩地三中心容災；無需引入第三方 HA，同步等組件，減少了相關軟硬件和網絡要求；補丁代碼量 100 行以內，僅需對主機房邊界節點升級，風險可控。具備規模實例運維場景下成熟，低成本，簡單可靠的特點，能夠和公司一鍵切換平臺快速集成。未來也具備支撐三地五中心等更高等級容災要求的能力。
依托數據庫多通道主主復制數據容災技術，機房容災切換時間由傳統的 30 分鐘降低到 5 分鐘，相關腳本集成到自動化平臺后進一步降低到 2 分鐘以內。機房回切效率由傳統的 1 小時降低到 5 分鐘以內。切換成功率 98% 以上。但該方案不支持多層級聯復制，同時也不支持列、記錄級等更精細化靈活控制的能力。
