簡介災(zāi)備切換流程是一份面向企業(yè)災(zāi)備應(yīng)急小組、系統(tǒng)運(yùn)維及開發(fā)測試人員的DOCX操作文檔聚焦主交易系統(tǒng)故障或?yàn)?zāi)難時(shí)如何規(guī)范高效切換至災(zāi)備系統(tǒng)保障業(yè)務(wù)連續(xù)性與數(shù)據(jù)一致性。文檔內(nèi)容覆蓋災(zāi)備原理與中心架構(gòu)、培訓(xùn)對象及內(nèi)容、演練級別與方式、演練環(huán)境設(shè)置、完整切換操作流程、切換后數(shù)據(jù)核對要點(diǎn)并區(qū)分計(jì)劃演練與突擊演練給出機(jī)房停電、鏈路故障、服務(wù)器故障等模擬場景兼顧雙活互備的雙向切換驗(yàn)證。資源共1個docx文件壓縮包約19KB頁面結(jié)構(gòu)清晰可直接用于災(zāi)備制度落地參考。目前已有294人學(xué)習(xí)下載適合正在建設(shè)容災(zāi)體系或需要完善災(zāi)備演練方案的單位參考使用。1. 災(zāi)備切換流程不是技術(shù)問題是決策問題真到了機(jī)房斷電或核心數(shù)據(jù)庫卡死的那天最難的不是命令怎么敲而是按下切換按鈕前那幾分鐘的猶豫。災(zāi)備切換流程這個標(biāo)題說白了就是一套“什么條件必須切、按什么順序切、切完怎么確認(rèn)、確認(rèn)完怎么回切”的完整動作序列。很多人以為災(zāi)備就是同步數(shù)據(jù)、定期做個備份但切過的人都知道真正的分水嶺在“執(zhí)行切換”那一刻同步了多少數(shù)據(jù)、業(yè)務(wù)入口在哪里、啟動順序?qū)Σ粚Α⑶型旮也桓曳帕髁棵總€環(huán)節(jié)都能讓整個流程卡死。這篇文章服務(wù)的是運(yùn)維、DBA、SRE 和負(fù)責(zé)系統(tǒng)架構(gòu)的人。你會看到我的處理思路先把切換的本質(zhì)看成一次狀態(tài)遷移再給出一套能落地的三層切換順序然后是決策表和防腦裂的參數(shù)設(shè)計(jì)最后落到回切和自動化驗(yàn)證。這套流程不是某個產(chǎn)品的官方文檔而是做災(zāi)備切換最常見的工程解法直接可抄但每個參數(shù)都值得你按自己的環(huán)境重調(diào)。2. 切換的本質(zhì)狀態(tài)遷移與 RPO/RTO 邊界2.1 災(zāi)備切換和內(nèi)核上下文切換在思路上是同源的最新的 freertos 內(nèi)核切換流程里任務(wù)切換要做的事情是保存當(dāng)前任務(wù)上下文、選定下一個任務(wù)、恢復(fù)新任務(wù)上下文。災(zāi)備切換流程在抽象層面上完全一致保存生產(chǎn)端數(shù)據(jù)狀態(tài)、把流量切到災(zāi)備端、恢復(fù)業(yè)務(wù)上下文。只不過內(nèi)核保存的是寄存器現(xiàn)場災(zāi)備切換保存的是數(shù)據(jù)庫日志位點(diǎn)、消息隊(duì)列消費(fèi)位點(diǎn)、分布式緩存里的會話數(shù)據(jù)。理解這一點(diǎn)對你有實(shí)際幫助任何切換的第一步都不是“啟動災(zāi)備”而是“確認(rèn)生產(chǎn)端狀態(tài)是否已經(jīng)被完整封存”。沒封存就切切完數(shù)據(jù)對不上整個流程就失去了意義。從操作上講封存狀態(tài)最核心的動作是記錄同步位點(diǎn)。Oracle DataGuard 看SEQUENCE#和THREAD#MySQL 主從看File和PositionKafka 看 consumer offset。你把這些值在切換前記錄到控制文件里后面回切、對賬、排查數(shù)據(jù)差異就都有基準(zhǔn)。為了讓這套流程可復(fù)用我會把“狀態(tài)封存”單獨(dú)設(shè)為一個檢查項(xiàng)任何切換腳本的第一段一定是收集和凍結(jié)位點(diǎn)。2.2 RPO 與 RTO切換流程參數(shù)設(shè)計(jì)的源頭災(zāi)備切換流程里的所有參數(shù)追到底都是為了滿足你在 SLA 里寫下的 RPO 和 RTO。RPO 是允許丟多少數(shù)據(jù)RTO 是允許多久恢復(fù)。這兩個值決定了你的復(fù)制選型RPO 接近零就得走同步復(fù)制或者存儲雙活RPO 可以接受幾分鐘異步復(fù)制就夠。RTO 決定了切換流程里哪些步驟可以串行哪些必須提前預(yù)熱。常見做法是切換編排系統(tǒng)把 RTO 預(yù)算拆成幾個部分狀態(tài)確認(rèn)預(yù)留 20%、切換執(zhí)行 50%、切換后驗(yàn)證 30%這樣在慌忙時(shí)還能留出反復(fù)確認(rèn)的空間。一個常見誤判是把 RPO 和 RTO 當(dāng)成“越大越好”。實(shí)際上RPO 要求越高生產(chǎn)端 IO 受影響越大因?yàn)橥綇?fù)制每次寫入都要等遠(yuǎn)端確認(rèn)RTO 要求越嚴(yán)你就必須常年預(yù)留一套熱備環(huán)境成本翻倍。設(shè)計(jì)災(zāi)備切換流程的第一步就是和業(yè)務(wù)方把 RPO/RTO 簽成一張表而不是讓運(yùn)維單方面想辦法。容災(zāi)架構(gòu)數(shù)據(jù)一致性典型 RPO典型 RTO適用場景異步復(fù)制 冷備可能丟最近數(shù)分鐘數(shù)據(jù)分鐘級小時(shí)級內(nèi)部系統(tǒng)、可容忍數(shù)據(jù)丟失的批量任務(wù)同步復(fù)制 熱備基本不丟數(shù)據(jù)秒級或零分鐘級交易系統(tǒng)、支付、訂單存儲雙活 應(yīng)用雙活不丟數(shù)據(jù)零秒級到分鐘級核心交易、監(jiān)管有要求的高可用場景備份 重搭建依賴最近一次備份天級天級開發(fā)測試環(huán)境、非關(guān)鍵系統(tǒng)選擇哪一種直接決定下一步三層切換流程中哪些環(huán)節(jié)必須自動化哪些可以接受人工介入。同步復(fù)制下數(shù)據(jù)層切換幾乎不需要等日志追平異步復(fù)制就得反復(fù)檢查延遲歸零。3. 落地最小切換流程數(shù)據(jù)層、網(wǎng)絡(luò)層、應(yīng)用層三層切換3.1 一個可復(fù)用的三層切換執(zhí)行順序真正執(zhí)行災(zāi)備切換時(shí)順序稍有錯誤就會造成連帶來的坑。我一般把流程固定成“數(shù)據(jù)層先行、網(wǎng)絡(luò)層承上、應(yīng)用層最后”這套順序在大多數(shù)主備架構(gòu)里都通用。先切數(shù)據(jù)層是因?yàn)閼?yīng)用起來的瞬間就要讀寫數(shù)據(jù)數(shù)據(jù)沒就緒應(yīng)用層啟動是空轉(zhuǎn)網(wǎng)絡(luò)層放在中間是因?yàn)榱髁看虻叫碌膽?yīng)用節(jié)點(diǎn)后必須能立刻找到新的數(shù)據(jù)節(jié)點(diǎn)期間依賴轉(zhuǎn)發(fā)規(guī)則先落地。一個典型的最小切換流程如下適合作為新環(huán)境的基準(zhǔn)模板#!/usr/bin/env bash # switchover.sh - 最小災(zāi)備切換流程 # 需要傳入環(huán)境標(biāo)識和預(yù)確認(rèn)標(biāo)記./switchover.sh prod confirm ENV$1 CONFIRM$2 if [ $CONFIRM ! confirm ]; then echo 請顯式傳入 confirm 參數(shù)以確認(rèn)切換 exit 1 fi # 步驟1封存生產(chǎn)端狀態(tài)記錄位點(diǎn) mysql -h 192.168.10.10 -u dba -p --batch \ -e SHOW MASTER STATUS; /switch/state/primary_position_$(date %s).txt echo [$(date %F %T)] primary state frozen /switch/log/failover.log # 步驟2數(shù)據(jù)層切換將災(zāi)備庫提升為主庫 mysql -h 192.168.20.10 -u dba -p \ -e STOP SLAVE; RESET SLAVE ALL; mysql -h 192.168.20.10 -u dba -p \ -e ALTER TABLE ...; # 具體命令由復(fù)制架構(gòu)決定此處為 MySQL MHA 風(fēng)格的簡化 # 步驟3觸發(fā)網(wǎng)絡(luò)層vIP漂移 ip addr add 192.168.100.50/24 dev eth0:backup arping -I eth0 -c 3 192.168.100.50 || true # 步驟4啟動災(zāi)備應(yīng)用服務(wù)注冊到注冊中心 /opt/app/bin/startup.sh --profile disaster echo [$(date %F %T)] failover finished /switch/log/failover.log這段腳本的邏輯順序說明第一步的SHOW MASTER STATUS是狀態(tài)封存把生產(chǎn)庫當(dāng)前 binlog 位置記錄到帶時(shí)間戳的文件里這是整個流程的基準(zhǔn)點(diǎn)第二步STOP SLAVE把災(zāi)備庫提升為主庫同時(shí)防止原復(fù)制線程繼續(xù)拉取數(shù)據(jù)第三步 vIP 漂移解決的是業(yè)務(wù)連接不修改的問題應(yīng)用仍然連接同一個 IParping用來刷新交換機(jī)上的 ARP 緩存讓新 IP 地址歸屬立即生效第四步啟動災(zāi)備應(yīng)用。參數(shù)里--profile disaster是 Spring Boot 風(fēng)格的環(huán)境參數(shù)不是必須項(xiàng)這里只是示意應(yīng)用要以災(zāi)備配置啟動。3.2 復(fù)制架構(gòu)決定數(shù)據(jù)層切換的具體指令不同復(fù)制架構(gòu)下數(shù)據(jù)層切換的指令差別很大。Oracle DataGuard 有兩種形態(tài)SWITCHOVER是計(jì)劃內(nèi)切換兩邊日志完整可以無損切回FAILOVER是在生產(chǎn)端不可用時(shí)強(qiáng)制激活災(zāi)備端這種情況下原生產(chǎn)庫重新上線必須走完整的重新同步流程否則會造成數(shù)據(jù)覆蓋。MySQL 的 MHA 和 Orchestrator 則會把從庫提升和新主庫的重新復(fù)制做成一體化的動作。參數(shù)上有一個容易被忽略的關(guān)鍵點(diǎn)異步復(fù)制環(huán)境下判斷“能否切換”的唯一標(biāo)準(zhǔn)是災(zāi)備端日志應(yīng)用延遲。常見做法是在切換前連續(xù)取三次Seconds_Behind_Master值全部歸零才允許往下走。如果生產(chǎn)庫已經(jīng)不可用就只能接受 RPO 預(yù)算內(nèi)的數(shù)據(jù)丟失不要花時(shí)間去追一個永遠(yuǎn)追不上的位點(diǎn)那會超 RTO。提示如果復(fù)制鏈路正在追趕中但你被迫切換務(wù)必在原生產(chǎn)庫上執(zhí)行SET GLOBAL read_onlyON或等價(jià)操作或者直接切斷主機(jī)網(wǎng)絡(luò)粗暴但有效然后記錄當(dāng)前位點(diǎn)。這是防腦裂的前置動作。3.3 網(wǎng)絡(luò)層切換的三種方式與適用邊界網(wǎng)絡(luò)層是切換流程里最容易模糊處理的一塊。常見做法有三種通過 DNS 改解析記錄、通過負(fù)載均衡器調(diào) upstream、通過虛擬 IP 漂移。DNS 方式延遲最高因?yàn)橐?TTL 過期適合對切換時(shí)間不敏感的場景負(fù)載均衡方式切換最干凈只需要更新上游節(jié)點(diǎn)列表但前提是你得確保所有客戶端都走 LBvIP 漂移適合直連架構(gòu)依賴 ARP 刷新切換快但需要保證交換機(jī)配置允許地址移動。這三者優(yōu)先級我一般這么排有統(tǒng)一流量入口就用 LB 切換入口不可控時(shí)用 vIP 漂移只在沒有其他手段時(shí)才用 DNS。一個常見坑是舊主庫的網(wǎng)絡(luò)接口在切換后仍然存活這時(shí)候新主庫的寫入和舊主庫的殘留進(jìn)程同時(shí)操作磁盤形成雙主。所以網(wǎng)絡(luò)層切換必須配一個 fencing 動作關(guān)掉舊主庫的業(yè)務(wù)進(jìn)程或者切斷它的存儲訪問。寧可舊主庫直接宕機(jī)也不能讓它半死不活地留在集群里。4. 實(shí)戰(zhàn)切換流程決策表、runbook 與防腦裂參數(shù)4.1 切換決策表從觀測指標(biāo)到執(zhí)行動作很多切換流程失敗不是執(zhí)行環(huán)節(jié)出問題而是發(fā)生故障時(shí)沒人能回答“到底切不切”。建議你把觸發(fā)條件寫成一張機(jī)讀決策表每個條件對應(yīng)最小觀測時(shí)間、觸發(fā)閾值、執(zhí)行動作。下面是一張我在 MySQL 主備場景下常用的決策表參數(shù)值需要根據(jù)你自己的 RPO/RTO 調(diào)整觀測指標(biāo)安全閾值危險(xiǎn)閾值持續(xù)觀測時(shí)間決策動作主庫心跳經(jīng)獨(dú)立心跳網(wǎng)絡(luò) 2s≥ 15s3 個周期主庫疑似不可用進(jìn)入切換候命復(fù)制延遲 Seconds_Behind_Master歸零 60s 且持續(xù)增長5 分鐘不容忍丟失等待追平可容忍則執(zhí)行切換主庫磁盤 IO 利用率 70% 95%10 分鐘先擴(kuò)容限流不直接切換應(yīng)用錯誤率健康檢查探針 1% 30%3 分鐘結(jié)合數(shù)據(jù)層狀態(tài)決定切換網(wǎng)絡(luò)丟包率對端機(jī)房 0.1% 10%30 秒確認(rèn)是單方向還是雙向避免誤切后無法同步?jīng)Q策表的作用是讓人在高壓下做判斷題而不是做計(jì)算題。表格里最關(guān)鍵的一列是“持續(xù)觀測時(shí)間”它解決的是抖動誤判問題。很多切換事故是心跳丟了幾秒就立刻觸發(fā)動作結(jié)果主庫根本沒掛切過去反而把好的環(huán)境搞壞了。生產(chǎn)環(huán)境的經(jīng)驗(yàn)值是至少觀測 3 個周期確認(rèn)是持續(xù)性故障而不是瞬時(shí)抖動。4.2 runbook 編排細(xì)化到每一條可驗(yàn)證的依賴有了決策表下一步是把切換流程做成 runbook。一個實(shí)用的 runbook 不是把命令按順序抄一遍而是把每個步驟拆成“前置檢查、執(zhí)行動作、結(jié)果確認(rèn)、失敗回退”四段。拿第 3 章那個最小流程舉例數(shù)據(jù)層切換的 runbook 可以拆成下面這樣的表格結(jié)構(gòu)執(zhí)行步驟前置條件執(zhí)行動作成功標(biāo)志失敗回退1. 凍結(jié)生產(chǎn)寫入復(fù)制鏈路正常設(shè)置read_onlyONSHOW VARIABLES確認(rèn)關(guān)閉 read_only 恢復(fù)2. 追平復(fù)制延遲無新寫入持續(xù)觀測Seconds_Behind_Master連續(xù) 3 次為 0回退并評估數(shù)據(jù)丟失3. 提升災(zāi)備庫步驟 2 通過STOP SLAVE; RESET SLAVE ALL可讀寫新庫原主庫暫不啟動4. 業(yè)務(wù)探活應(yīng)用啟動完成調(diào)用健康檢查接口返回 200檢查依賴服務(wù)狀態(tài)runbook 里最容易忽略的是“失敗回退”這一列。多數(shù)人只寫成功路徑但不寫失敗后怎么辦。實(shí)戰(zhàn)中最危險(xiǎn)的狀態(tài)不是切換失敗而是切到一半卡住數(shù)據(jù)層已經(jīng)切換、應(yīng)用沒起來、舊主庫也不讓寫。所以 runbook 里每一行都必須定義失敗時(shí)是繼續(xù)往下推還是退回上一步以及退回的代價(jià)是什么。提示runbook 必須每年至少做一次實(shí)際演練。紙面上“看起來很通”的流程往往在演練時(shí)會發(fā)現(xiàn)數(shù)據(jù)目錄掛載路徑不一致、注冊中心地址沒改、定時(shí)任務(wù)還在往舊庫寫數(shù)據(jù)這類問題。演練時(shí)故意注入的故障越多真實(shí)切換時(shí)的成功率越高。4.3 防腦裂參數(shù)fencing 與 quorum 的工程配置腦裂發(fā)生在兩端同時(shí)認(rèn)為自己是主庫的狀態(tài)下根因通常是主庫還活著但網(wǎng)絡(luò)分區(qū)了災(zāi)備端探測不到主庫心跳所以接管。最有效的防腦裂手段不是增高探測閾值而是引入 quorum 機(jī)制。常見做法是用 etcd 或 Zookeeper 維護(hù)一個節(jié)點(diǎn)列表只有獲得多數(shù)票的節(jié)點(diǎn)才有資格持有主庫狀態(tài)這樣網(wǎng)絡(luò)分區(qū)時(shí)只有少數(shù)派會被剝奪主庫資格。數(shù)據(jù)庫層面也可以在切換前執(zhí)行FLUSH TABLES WITH READ LOCK確認(rèn)拿到鎖之后才允許后續(xù)切換動作。更硬核一點(diǎn)的防腦裂參數(shù)是 storage-level fencing比如 SAN 存儲里通過 LUN 鎖定或 SCSI-3 Persistent Reservation 禁止舊主庫繼續(xù)訪問共享存儲。數(shù)據(jù)庫服務(wù)層面可以配合read_onlyON雙保險(xiǎn)。這條參數(shù)在切換流程里不是一個可選優(yōu)化而是必須有的動作。沒有 fencing 的災(zāi)備切換就等于同時(shí)向兩個方向?qū)懭氲亩〞r(shí)炸彈一旦檢測到兩端數(shù)據(jù)錯位回切成本會變成災(zāi)難級。5. 回切比切換更難自動驗(yàn)證與冪等切換腳本回切通常發(fā)生在災(zāi)備環(huán)境穩(wěn)定運(yùn)行幾天、生產(chǎn)環(huán)境修復(fù)完成后。危險(xiǎn)在于回切時(shí)數(shù)據(jù)流方向必須反向原災(zāi)備庫現(xiàn)在新的生產(chǎn)的增量數(shù)據(jù)要同步回原生產(chǎn)庫。異步復(fù)制架構(gòu)下這些增量數(shù)據(jù)如果沒追平就切回去會再次產(chǎn)生數(shù)據(jù)丟失?；厍辛鞒涛視~外加兩件套先做追平確認(rèn)再做數(shù)據(jù)校驗(yàn)抽樣。數(shù)據(jù)校驗(yàn)用行數(shù)和 checksum 對比而不是只查一條最大 ID 就算數(shù)。最后給出一個我始終在用的技巧——把整個切換流程做成冪等腳本。冪等的意思是同一個腳本停在任意一步后重跑不會產(chǎn)生重復(fù)副作用。核心做法是先檢查當(dāng)前狀態(tài)再決定動作。實(shí)現(xiàn)方案是在每個節(jié)點(diǎn)上維護(hù)一個狀態(tài)文件記錄當(dāng)前處于哪個流程階段腳本每次啟動讀它。#!/usr/bin/env bash # idempotent_switch_state.sh - 冪等化切換狀態(tài)檢查 STATE_DIR/switch/state STATE_FILE$STATE_DIR/failover_state.conf # 狀態(tài)編碼: primary | frozen | failover_executed | failover_verified | switchback get_state() { if [ -f $STATE_FILE ]; then cat $STATE_FILE else echo primary fi } # 狀態(tài)遷移規(guī)則只有在允許的路徑上才繼續(xù)執(zhí)行 can_transit() { local current$1 local next$2 case $current:$next in primary:frozen|frozen:failover_executed|failover_executed:failover_verified|failover_verified:switchback) return 0 ;; *) return 1 ;; esac } current$(get_state) next${1:-frozen} if can_transit $current $next; then echo $next $STATE_FILE echo 狀態(tài)已推進(jìn): $current - $next else echo 非法狀態(tài)遷移: $current - $next已阻止 exit 1 fi這段腳本的邏輯說明get_state 負(fù)責(zé)讀取當(dāng)前狀態(tài)狀態(tài)文件不存在時(shí)默認(rèn)認(rèn)為還在生產(chǎn)態(tài)can_transit 定義合法的遷移路徑比如frozen只能遷向failover_executed不允許跳步如果腳本因?yàn)槟硞€環(huán)節(jié)失敗重復(fù)執(zhí)行它會因?yàn)闋顟B(tài)沖突被攔截不會重復(fù)觸發(fā)切換動作。參數(shù)上默認(rèn)推進(jìn)目標(biāo)是frozen實(shí)際使用可以傳入failover_executed等值配合外部編排系統(tǒng)按階段調(diào)用。狀態(tài)碼的含義是primary 表示投產(chǎn)運(yùn)行frozen 表示生產(chǎn)狀態(tài)被封存failover_executed 表示災(zāi)備接管已執(zhí)行failover_verified 表示接管后驗(yàn)證通過switchback 表示回切完成。有了這個狀態(tài)文件再結(jié)合決策表里的觀測指標(biāo)自動更新狀態(tài)就可以把人工減災(zāi)流程改造成半自動化的“按階段確認(rèn)推進(jìn)”模式。每推進(jìn)一步輸出當(dāng)前狀態(tài)出問題時(shí)所有相關(guān)人看的是一致的進(jìn)度而不是群聊里互相問“現(xiàn)在到哪了”。這個技巧在任何規(guī)模的災(zāi)備切換流程里都值得保留因?yàn)槿祟愒诟邏合碌闹貜?fù)記憶不可靠機(jī)器的狀態(tài)文件不會說謊。本文還有配套的精品資源點(diǎn)擊獲取