作者 | 徐良
背景介紹
在雲網融合大數據時代，數據已經成為重要的生產要素。特別是稜鏡門、永恆之藍、汶川大地震這類造成大規模數據丟失和泄漏的人為或自然災害事件發生後，中國相繼出台了一系列的法律法規，對各組織機構的數據安全保護條件進行限定，如 2016 年頒布的《中華人民共和國網絡安全法》、 2021 年全國人民代表大會通過的《數據安全法》等。
當發生災難時，容災備份能夠確保數據不丟失。要實現應用的容災，一個關鍵就是通過資料庫的實時同步和複製，在 A 地出現機房故障和問題的時候可以平滑快速的遷移到 B 地。雖然這種遠程數據複製和同步存在一定的延遲，但是基本可以滿足業務連續性的需求。
容災的基礎概述
容災的定義
容災是指當數據中心發生各種未知災難的時候，確保數據不丟失或少丟失，同時 IT 業務系統能夠不間斷運行或快速切換恢復。
災難的衡量指標
評估一個災備系統可靠性的兩個重要指標是 RTO 與 RPO。
RTO (Recovery Time Objective)恢復時間目標。RTO 是指災難發生後，從系統宕機導致業務停頓之刻開始，到系統恢復至可以支持業務部門運作，業務恢復運營之時，此兩點之間的時間。RTO 可簡單地描述為企業能容忍的恢復時間。
RPO (Recovery Point Objective) 恢復點目標。RPO 是指災難發生後，容災系統能把數據恢復到災難發生前時間點的數據，它是衡量企業在災難發生後會丟失多少生產數據的指標。RPO 可簡單地描述為企業能容忍的最大數據丟失量。RTO 針對的是服務時間的丟失，RPO 針對的是數據的丟失，兩者是衡量容災系統的兩個主要指標，但它們沒有必然的關聯性。
容災的等級分類
2007 年 11 月 1 日開始正式實施的國家標準 (GB/T 20988-2007) 是我國災難備份與恢復行業的第一個國家標準。
災難與 RTO、RPO 的關係
兩地三中心容災
兩地三中心能夠組合本地高可用，同城災備中心，異地災備中心，提高可用性，提升業務連續性，重點業務多採用「兩地三中心」（即生產數據中心、同城災備中心、異地災備中心）建設方案。這種模式下，多個數據中心是主備關係，針對災難的響應與切換周期根據異常情況靈活處理，能夠實現更優的 RTO 與 RPO 整體目標。
MySQL 常見的主從形式
MySQL 本身就自帶有主從複製的功能，解決了幾個關鍵的問題：數據一致性、檢查點機制、可靠網絡傳輸等，可以幫助我們實現高可用切換和讀寫分離。
一主一從
一主一從能夠提供備庫，主庫故障後可以進行故障切換，避免數據丟失。
一主多從
一主多從常見的主從架構，使用起來簡單有效，不僅可以實現 HA，而且還能讀寫分離，進而提升集群的並發能力。
多主一從
多主一從可以將多個 MySQL 資料庫備份到一台存儲性能比較好的伺服器上，方便統一分析處理。
雙主複製
雙主複製，也就是互做主從複製，每個 master 既是 master，又是另外一台伺服器的 slave。這樣任何一方所做的變更，都會通過複製應用到另外一方的資料庫中。同一時刻可以只有一個是主，另外一個是備，實例主動維護進行主從切換的時候無需進行特別的配置，秒級切換方便日常升級維護。
級聯複製
級聯複製模式下，部分 slave 的數據同步不連接主節點，而是連接從節點。主節點有太多的從節點，就會損耗一部分性能用於 replication ，這個時候可以讓 3~5 個從節點連接主節點，其它從節點作為二級或者三級與從節點連接，這樣不僅可以緩解主節點的壓力，並且對數據一致性沒有負面影響。
兩地三中心 MySQL 主從複製
MySQL 常見高可用方案優劣
對比目前主流的資料庫高可用方案，都有各自的優勢和劣勢，但在支持異地容災方面都不夠簡單易用：
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，避免多通道主主時數據迴路的問題。
總 結
該 MySQL 數據同步方案優化了 MySQL 本身的日誌同步機制，引入多通道主主複製技術，降低了機房容災演練和回切時數據同步關係調整帶的複雜性；每個通道僅同步臨近主庫 binlog event，解決了數據迴路問題，支撐重點業務兩地三中心容災；無需引入第三方 HA，同步等組件，減少了相關軟硬體和網絡要求；補丁代碼量 100 行以內，僅需對主機房邊界節點升級，風險可控。具備規模實例運維場景下成熟，低成本，簡單可靠的特點，能夠和公司一鍵切換平台快速集成。未來也具備支撐三地五中心等更高等級容災要求的能力。
依託資料庫多通道主主複製數據容災技術，機房容災切換時間由傳統的 30 分鐘降低到 5 分鐘，相關腳本集成到自動化平台後進一步降低到 2 分鐘以內。機房回切效率由傳統的 1 小時降低到 5 分鐘以內。切換成功率 98% 以上。但該方案不支持多層級聯複製，同時也不支持列、記錄級等更精細化靈活控制的能力。
作者簡介：
徐良，現任中國移動智慧家庭運營中心資料庫高級經理，多年資料庫運維優化經驗，歷任華為、一線網際網路公司高級 DBA。目前主要負責中移智家基於規模的價值運營場景下資料庫穩定性、容災優化、異地多活等相關工作。
「谷歌有谷歌的規矩」
丟掉 LangChain、像 Docker一樣編排大模型應用程式：這支十餘人的年輕創業團隊如何在2個月做出一個LLMOps平台？
僅憑 7 頁 PPT 拿下 1 億美元融資、半年後估值超 10 億！「歐洲 OpenAI」殺瘋了
易鯨捷否認貼牌 Oracle；鴻蒙進教材：「純血」版不再兼容安卓應用；大叔們遭AI女友「斷崖式分手」 | Q 資訊