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