文章中介紹了多種 MySQL 高可用技術，并介紹了根據(jù)自身需求選擇多通道主主復制技術的過程和注意事項。

作者：徐良，現(xiàn)任中國移動智慧家庭運營中心數(shù)據(jù)庫高級經(jīng)理，多年數(shù)據(jù)庫運維優(yōu)化經(jīng)驗，歷任華為、一線互聯(lián)網(wǎng)公司高級 DBA。目前主要負責中移智家基于規(guī)模的價值運營場景下數(shù)據(jù)庫穩(wěn)定性、容災優(yōu)化、異地多活等相關工作。

愛可生開源社區(qū)出品，原創(chuàng)內(nèi)容未經(jīng)授權不得隨意使用，轉載請聯(lián)系小編并注明來源。

本文約 2800 字，預計閱讀需要 7 分鐘。

背景介紹

在云網(wǎng)融合大數(shù)據(jù)時代，數(shù)據(jù)已經(jīng)成為重要的生產(chǎn)要素。特別是棱鏡門、永恒之藍、汶川大地震這類造成大規(guī)模數(shù)據(jù)丟失和泄漏的人為或自然災害事件發(fā)生后，中國相繼出臺了一系列的法律法規(guī)，對各組織機構的數(shù)據(jù)安全保護條件進行限定，如 2016 年頒布的《中華人民共和國網(wǎng)絡安全法》、 2021 年全國人民代表大會通過的《數(shù)據(jù)安全法》等。

當發(fā)生災難時，容災備份能夠確保數(shù)據(jù)不丟失。要實現(xiàn)應用的容災，一個關鍵就是通過數(shù)據(jù)庫的實時同步和復制，在 A 地出現(xiàn)機房故障和問題的時候可以平滑快速的遷移到 B 地。雖然這種遠程數(shù)據(jù)復制和同步存在一定的延遲，但是基本可以滿足業(yè)務連續(xù)性的需求。

容災的基礎概述

容災的定義

容災是指當數(shù)據(jù)中心發(fā)生各種未知災難的時候，確保數(shù)據(jù)不丟失或少丟失，同時 IT 業(yè)務系統(tǒng)能夠不間斷運行或快速切換恢復。

災難的衡量指標

評估一個災備系統(tǒng)可靠性的兩個重要指標是 RTO 與 RPO。

RTO (Recovery Time Objective) 恢復時間目標。RTO 是指災難發(fā)生后，從系統(tǒng)宕機導致業(yè)務停頓之刻開始，到系統(tǒng)恢復至可以支持業(yè)務部門運作，業(yè)務恢復運營之時，此兩點之間的時間。RTO 可簡單地描述為企業(yè)能容忍的恢復時間。

RPO (Recovery Point Objective) 恢復點目標。RPO 是指災難發(fā)生后，容災系統(tǒng)能把數(shù)據(jù)恢復到災難發(fā)生前時間點的數(shù)據(jù)，它是衡量企業(yè)在災難發(fā)生后會丟失多少生產(chǎn)數(shù)據(jù)的指標。RPO可簡單地描述為企業(yè)能容忍的最大數(shù)據(jù)丟失量。

RTO 針對的是服務時間的丟失，RPO 針對的是數(shù)據(jù)的丟失，兩者是衡量容災系統(tǒng)的兩個主要指標，但它們沒有必然的關聯(lián)性。

容災的等級分類

2007 年 11 月 1 日開始正式實施的國家標準 (GB/T 20988-2007) 是我國災難備份與恢復行業(yè)的第一個國家標準。

等級	說明
第 1 級	基本級。備份介質場外存，安全保障、 定期驗證。
第 2 級	備份場地支持。網(wǎng)絡和業(yè)務處理系統(tǒng)可在預定時間內(nèi)調(diào)配到備份中心。
第 3 級	電子傳輸和部分設備支持。災備中心配備部分業(yè)務處理和網(wǎng)絡設備，具備部分通訊鏈路。
第 4 級	電子傳輸和完整設備支持。數(shù)據(jù)定時批量傳送，網(wǎng)絡/系統(tǒng)始終就緒。溫備中心模式。
第 5 級	實時數(shù)據(jù)傳輸及完整設備支持。采用遠程復制技術，實現(xiàn)數(shù)據(jù)實時復制，網(wǎng)絡具備自動或集中切換能力，業(yè)務處理系統(tǒng)就緒或運行中。
第 6 級	數(shù)據(jù)零丟失和遠程集群支持。數(shù)據(jù)實時備份，零丟失，系統(tǒng) /應用遠程集群，可自動切換，用戶同時接入主備中心。

災難與 RTO、RPO 的關系

災難恢復能力等級	RTO	RPO
1	2 天以上	1 天至 7 天
2	24 小時以后	1 天至 7 天
3	12 小時以上	數(shù)小時至 1 小時
4	數(shù)小時至 2 天	數(shù)小時至 1 小時
5	數(shù)分鐘至 2 天	0 至 30 分鐘
6	數(shù)分鐘	0

兩地三中心容災

兩地三中心能夠組合本地高可用，同城災備中心，異地災備中心，提高可用性，提升業(yè)務連續(xù)性，重點業(yè)務多采用“兩地三中心”（即生產(chǎn)數(shù)據(jù)中心、同城災備中心、異地災備中心）建設方案。這種模式下，多個數(shù)據(jù)中心是主備關系，針對災難的響應與切換周期根據(jù)異常情況靈活處理，能夠實現(xiàn)更優(yōu)的 RTO 與 RPO 整體目標。

MySQL 常見的主從形式

MySQL 本身就自帶有主從復制的功能，解決了幾個關鍵的問題：數(shù)據(jù)一致性、檢查點機制、可靠網(wǎng)絡傳輸?shù)?#xff0c;可以幫助我們實現(xiàn)高可用切換和讀寫分離。

一主一從

一主一從能夠提供備庫，主庫故障后可以進行故障切換，避免數(shù)據(jù)丟失。

一主多從

一主多從常見的主從架構，使用起來簡單有效，不僅可以實現(xiàn) HA，而且還能讀寫分離，進而提升集群的并發(fā)能力。

多主一從

多主一從可以將多個 MySQL 數(shù)據(jù)庫備份到一臺存儲性能比較好的服務器上，方便統(tǒng)一分析處理。

雙主復制

雙主復制，也就是互做主從復制，每個 master 既是 master，又是另外一臺服務器的 slave。這樣任何一方所做的變更，都會通過復制應用到另外一方的數(shù)據(jù)庫中。同一時刻可以只有一個是主，另外一個是備，實例主動維護進行主從切換的時候無需進行特別的配置，秒級切換方便日常升級維護。

級聯(lián)復制

級聯(lián)復制模式下，部分 slave 的數(shù)據(jù)同步不連接主節(jié)點，而是連接從節(jié)點。主節(jié)點有太多的從節(jié)點，就會損耗一部分性能用于 replication ，這個時候可以讓 3~5 個從節(jié)點連接主節(jié)點，其它從節(jié)點作為二級或者三級與從節(jié)點連接，這樣不僅可以緩解主節(jié)點的壓力，并且對數(shù)據(jù)一致性沒有負面影響。

兩地三中心 MySQL 主從復制

MySQL 常見高可用方案優(yōu)劣

對比目前主流的數(shù)據(jù)庫高可用方案，都有各自的優(yōu)勢和劣勢，但在支持異地容災方面都不夠簡單易用：

高可用方案	優(yōu)勢	劣勢
主從 + Keepalived	部署簡單，沒有主實例宕機后選主的問題。	一主多從在切換之后，其他從實例需要重新配置連接新主。
MHA	支持一主多從、主服務崩潰時不會導致數(shù)據(jù)不一致。	SSH 存在安全隱患，官方不在維護。
組復制 MGR	無延遲，數(shù)據(jù)強一致性	強依賴網(wǎng)絡，只能用在 GTID 模式下，大事務和 DDL 操作有阻塞風險。
MySQL InnoDB Cluster	彌補組復制無法提供具有自動化故障轉移功能的中間件。	組件多，成熟案例少。
Orchestrator	支持一主多從，解決了管理節(jié)點的單點問題，支持命令行和 Web 界面管理復制。	功能復雜，不方便集成進自有系統(tǒng)。

MySQL 主從初始化消息

通過抓取消息和分析代碼，發(fā)現(xiàn) MySQL 從庫和主庫建立同步通道過程中，分別進行網(wǎng)絡連接建立、授權，實例唯一性、時鐘、字符集、binlog 配置校驗等工作。其中實例唯一性校驗過程從庫會獲取主庫的 server id。

MySQL binlog 日志結構

MySQL 的主從復制是基于 binlog 文件，而 binlog 文件是由多個 binlog event 構成，binlog event 的整體結構由 head+data+footer 三部分組成。head 包含產(chǎn)生 event 的數(shù)據(jù)庫實例 server id，在主從復制作為區(qū)分 event 是否為自己實例生成的重要依據(jù)。

之前通過主從初始化消息能夠獲取主從管道對端主庫的 server id，此時和從庫從管道內(nèi)接受的 event 的 server id 進行對比，能夠識別該 event 是否是當前對端主庫產(chǎn)生的。

兩地三中心 MySQL 主從方案 1

兩地三中心建設相對容易，日常的演練和數(shù)據(jù)回流等配置比較繁瑣，容易出錯。本方案通過機房內(nèi)建立 MySQL 主主復制，此時主從切換無需繁瑣的命令，只需要設置 read_only；同城機房間也是建立主主復制，方便容災演練回切，無需復雜的配置。同理，與兩地三中心 MySQL 也建立主主復制，方便演練和回切。該方案使用原生的 MySQL 復制，成熟度高；未過多引入第三方組件，具備規(guī)?；\維潛力。但原生的 MySQL 主從在多條鏈路存在主主復制時，會出現(xiàn)復制回路問題，導致數(shù)據(jù)沖突和不一致。

兩地三中心 MySQL 主從方案 2

為解決復制回路問題，在主機房邊界節(jié)點實例上，本方案使用上文中根據(jù)對端主庫 server id 判斷是否和 event 的 server id 相同，對 IDC1 邊界 MySQL 復制邏輯進行限制，只同步管道內(nèi)臨近主產(chǎn)生的 binlog 日志，級聯(lián)主日志丟棄，1 個同步管道只同步單臺 master 日志，解決回路問題。其他節(jié)點無需開啟這個功能。

邊界節(jié)點 MySQL 復制邏輯代碼補丁

本補丁基于社區(qū)版 MySQL 5.7.40 升級，修改 sys_vars.cc 文件，增加 replicate_server_mode 配置項（默認為 0），兼容原有復制模式，配置為 1 時主從同步僅同步管道內(nèi)對端主產(chǎn)生的 binlog event。

修改 log_event.cc 文件的 Log_event::do_shall_skip 函數(shù)，判斷當前 event 的 server_id 和本通道對端主庫 master 的 server_id 不相同時忽略，僅同步對端主庫產(chǎn)生的 event，避免多通道主主時數(shù)據(jù)回路的問題。

總結

該 MySQL 數(shù)據(jù)同步方案優(yōu)化了 MySQL 本身的日志同步機制，引入多通道主主復制技術，降低了機房容災演練和回切時數(shù)據(jù)同步關系調(diào)整帶的復雜性；每個通道僅同步臨近主庫 binlog event，解決了數(shù)據(jù)回路問題，支撐重點業(yè)務兩地三中心容災；無需引入第三方 HA，同步等組件，減少了相關軟硬件和網(wǎng)絡要求；補丁代碼量 100 行以內(nèi)，僅需對主機房邊界節(jié)點升級，風險可控。具備規(guī)模實例運維場景下成熟，低成本，簡單可靠的特點，能夠和公司一鍵切換平臺快速集成。未來也具備支撐三地五中心等更高等級容災要求的能力。但該方案不支持多層級聯(lián)復制，同時也不支持列、記錄級等更精細化靈活控制的能力。

更多技術文章，請訪問：https://opensource.actionsky.com/

關于 SQLE

SQLE 是一款全方位的 SQL 質量管理平臺，覆蓋開發(fā)至生產(chǎn)環(huán)境的 SQL 審核和管理。支持主流的開源、商業(yè)、國產(chǎn)數(shù)據(jù)庫，為開發(fā)和運維提供流程自動化能力，提升上線效率，提高數(shù)據(jù)質量。

SQLE 獲取

類型	地址
版本庫	https://github.com/actiontech/sqle
文檔	https://actiontech.github.io/sqle-docs/
發(fā)布信息	https://github.com/actiontech/sqle/releases
數(shù)據(jù)審核插件開發(fā)文檔	https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse