MySQL 主庫(kù)故障切換主要包括四個(gè)步驟。1. 故障檢測(cè)：通過(guò)監(jiān)控系統(tǒng)定期檢查主庫(kù)進(jìn)程、連接狀態(tài)及執(zhí)行簡(jiǎn)單查詢(xún)判斷是否宕機(jī)，設(shè)置重試機(jī)制避免誤判，并可借助 MHA、Orchestrator 或 Keepalived 等工具輔助檢測(cè)；2. 選擇新主庫(kù)：根據(jù)數(shù)據(jù)同步進(jìn)度（Seconds_Behind_Master）、binlog 數(shù)據(jù)完整性、網(wǎng)絡(luò)延遲與負(fù)載情況選取最合適從庫(kù)接替，必要時(shí)進(jìn)行數(shù)據(jù)補(bǔ)償或人工干預(yù)；3. 切換拓?fù)洌簩⑵渌麖膸?kù)指向新主庫(kù)，執(zhí)行 RESET MASTER 或啟用 GTID，更新 VIP、DNS 或代理配置以實(shí)現(xiàn)應(yīng)用透明切換；4. 應(yīng)用層配合：客戶(hù)端需支持自動(dòng)重連、異常處理、DNS 緩存刷新等機(jī)制，結(jié)合連接池中間件如 HikariCP 提升容錯(cuò)能力，確保服務(wù)無(wú)縫過(guò)渡。

MySQL 主庫(kù)故障切換（Master Failover）是高可用架構(gòu)中的關(guān)鍵環(huán)節(jié)，目的是在主庫(kù)出現(xiàn)異常時(shí)，快速將流量轉(zhuǎn)移到一個(gè)從庫(kù)上，保障服務(wù)持續(xù)可用。這個(gè)過(guò)程通常包括檢測(cè)故障、選擇新主庫(kù)、切換客戶(hù)端連接等幾個(gè)步驟。

1. 故障檢測(cè)：如何判斷主庫(kù)出問(wèn)題？

自動(dòng)或手動(dòng)確認(rèn)主庫(kù)是否真的宕機(jī)，是整個(gè)流程的第一步。常見(jiàn)的做法是通過(guò)監(jiān)控系統(tǒng)定期探測(cè)主庫(kù)的健康狀態(tài)，比如：

• 檢查 MySQL 進(jìn)程是否運(yùn)行
• 嘗試建立數(shù)據(jù)庫(kù)連接
• 執(zhí)行簡(jiǎn)單的 SQL 查詢(xún)（如 SELECT 1）

一旦連續(xù)多次失敗，就認(rèn)為主庫(kù)不可用。需要注意的是，網(wǎng)絡(luò)抖動(dòng)也可能導(dǎo)致誤判，所以通常會(huì)設(shè)置重試機(jī)制和超時(shí)時(shí)間，避免不必要的切換。

有些工具比如 MHA、Orchestrator 或者使用 Keepalived 等，都可以用來(lái)做故障檢測(cè)。

2. 選擇新的主庫(kù)：誰(shuí)來(lái)接班？

當(dāng)確認(rèn)主庫(kù)故障后，下一步就是從現(xiàn)有的從庫(kù)中選出一個(gè)合適的節(jié)點(diǎn)作為新的主庫(kù)。

選擇標(biāo)準(zhǔn)一般包括：

• 數(shù)據(jù)同步進(jìn)度（看 Seconds_Behind_Master）
• 是否有最新的 binlog 數(shù)據(jù)
• 網(wǎng)絡(luò)延遲和穩(wěn)定性
• 實(shí)例負(fù)載情況

理想情況下，應(yīng)該選數(shù)據(jù)最接近原主庫(kù)的那個(gè)從庫(kù)，這樣可以減少數(shù)據(jù)丟失的風(fēng)險(xiǎn)。如果多個(gè)從庫(kù)都落后很多，可能需要進(jìn)行數(shù)據(jù)補(bǔ)償或者人工干預(yù)。

MHA 會(huì)自動(dòng)嘗試補(bǔ)齊日志，而 Orchestrator 則可以通過(guò) API 查看拓?fù)浣Y(jié)構(gòu)并做出決策。

3. 切換拓?fù)洌鹤屍渌?jié)點(diǎn)知道新主是誰(shuí)

確定了新的主庫(kù)之后，接下來(lái)要做的就是把其他從庫(kù)指向新的主庫(kù)，并更新應(yīng)用層配置，確保寫(xiě)入請(qǐng)求能正確到達(dá)。

具體操作包括：

• 在新主庫(kù)執(zhí)行 RESET MASTER 或啟用 GTID
• 其他從庫(kù)執(zhí)行 CHANGE MASTER TO 指向新主
• 更新 VIP 或 DNS 配置，讓?xiě)?yīng)用透明切換
• 如果使用代理（如 ProxySQL、MaxScale），也要更新其配置

這一步的關(guān)鍵是盡量做到“無(wú)縫”，避免業(yè)務(wù)中斷。某些方案還會(huì)結(jié)合虛擬 IP 或者服務(wù)發(fā)現(xiàn)機(jī)制來(lái)簡(jiǎn)化切換邏輯。

4. 應(yīng)用層配合：別忘了客戶(hù)端

即使數(shù)據(jù)庫(kù)層面完成了切換，應(yīng)用如果沒(méi)有及時(shí)感知變化，還是會(huì)出現(xiàn)連接錯(cuò)誤。

為了應(yīng)對(duì)這個(gè)問(wèn)題，可以考慮以下幾種方式：

• 使用連接池中間件，支持自動(dòng)重連和讀寫(xiě)分離
• 在客戶(hù)端代碼中加入重試邏輯和異常處理
• 配合 DNS 緩存刷新策略，確保應(yīng)用拿到最新地址

例如，使用 Spring Boot 的 HikariCP 或 MyBatis，可以設(shè)置連接超時(shí)時(shí)間和最大重試次數(shù)，提升容錯(cuò)能力。

基本上就這些步驟了。雖然整體流程看起來(lái)不復(fù)雜，但實(shí)際部署中有很多細(xì)節(jié)容易忽略，比如復(fù)制延遲、GTID一致性、權(quán)限配置等問(wèn)題。建議在正式上線前多做演練，確保 failover 能順利執(zhí)行。

以上是MySQL Master故障轉(zhuǎn)移的典型過(guò)程是什么？的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！