本文說明幾種架構，可為 Google Cloud上的 MySQL 部署作業提供高可用性 (HA)。高可用性是衡量系統在底層基礎架構故障時的復原能力。本文探討的是單一雲端地區內 MySQL 叢集的可用性。
本文適用於資料庫管理員、雲端架構師和開發運作工程師，說明如何提高整體系統正常運作時間，進而提升 MySQL 資料層的可靠性。如果您在 Compute Engine 上執行 MySQL，這份文件將對您有所幫助。如果您使用 MySQL 適用的 Cloud SQL，這份文件不適用於您。
如果系統或應用程式需要持續狀態才能處理要求或交易，資料持續性層就必須可用，才能順利處理資料查詢或突變的要求。如果應用程式必須與資料層互動才能處理要求，資料層的任何停機時間都會導致應用程式無法執行必要工作。
視系統的系統服務等級目標 (SLO) 而定，您可能需要提供更高可用性的架構拓撲。實現高可用性有多種方法，但一般來說，您會佈建備援基礎架構，以便應用程式快速存取。
本文將探討下列主題：
- 定義詞彙，協助您瞭解高可用性資料庫概念。
- 協助您瞭解高可用性 MySQL 拓撲的幾種選項。
- 提供背景資訊，協助您瞭解每個選項的考量事項。
術語
有幾個業界標準的詞彙和概念，瞭解這些內容有助於您在本文範圍以外的用途。
複製。寫入交易 (INSERT、UPDATE 或 DELETE) 的程序，可確保交易內容確實擷取、記錄，然後依序套用至拓撲中的所有資料庫節點。
同步複製。這種資料複寫方法會同時寫入主要資料庫和複本資料庫，確保資料即時一致。
半同步複製。資料複製方法，可同時寫入主要資料庫和至少一個其他副本資料庫，確保資料一致性達到一定程度。
非同步複製。資料複製方法，可延遲更新主要和備用資源，優先考量效能而非立即一致性。
來源節點。所有資料庫寫入作業都必須導向來源節點。來源節點會提供讀取作業，其中包含保存資料的最新狀態。
副本節點。來源資料庫節點的線上副本。變更會從來源節點近乎同步複製到副本節點。您可以從副本節點讀取資料，但請注意，由於複製延遲，資料可能會稍微延遲。
複製延遲。時間測量值，表示交易套用至副本的時間與套用至來源節點的時間之間的差異。
運作時間。資源可運作並回應要求的時間百分比。
故障偵測。識別基礎架構故障的程序。
容錯移轉。將待命基礎架構 (在本例中為副本節點) 升級為主要基礎架構 (來源節點) 的程序。
復原時間目標 (RTO)。從業務角度來看，資料層可接受的離線時間長度 (以實際經過的時間計算)，直到容錯移轉程序完成為止。
復原點目標 (RPO)。從業務角度來看，在容許資料遺失的情況下，直到完成容錯移轉程序為止，可接受的經過時間長度。
Fallback。容錯移轉後，重新啟用先前來源節點的程序。
自動修復。系統在沒有人為操作員採取外部動作的情況下，解決問題的能力。
網路分割。拓撲中的兩個節點 (例如來源和副本節點) 無法透過網路彼此通訊的狀況。
核心分裂。兩個節點同時認為自己是來源節點時發生的情況。
節點群組。提供服務的一組運算資源工作。在本文件中，該服務是指資料持久層。
見證或法定人數節點。獨立的運算資源，可協助節點群組在發生腦裂情況時判斷該如何處理。
來源或領導者選舉。一組同層感知節點 (包括見證節點) 決定哪個節點應做為來源節點的程序。
節點群組。提供服務的一組運算資源工作。在本文件中，該服務是指資料持久層。
熱待命。節點代表另一個來源節點的近乎完美的副本，且可成為新的來源節點，停機時間極短。
高可用性架構的適用時機
高可用性架構可進一步防範資料層停機。 瞭解您對停機時間的容許程度，以及各種架構的相應取捨，對於選擇適合您業務用途的選項至關重要。
如要提高資料層的正常運作時間，以滿足工作負載和服務的可靠性要求，請使用高可用性拓撲。如果環境可容忍一定程度的停機時間，導入 HA 拓撲會造成不必要的成本和複雜度。舉例來說，開發或測試環境不常需要高資料庫層級可用性。
考量高可用性需求
成本是值得注意的考量因素，因為為了提供高可用性，您的運算基礎架構和儲存空間費用至少會增加一倍。請務必仔細評估這項成本，並與停機可能造成的財務影響進行比較。評估可能的 MySQL HA 選項時，請考量下列問題：
- 哪些服務或客戶依賴您的資料層？
- 您的營運預算為何？
- 如果資料持久層發生停機，貴商家會損失多少？
- 程序需要自動化到什麼程度？
- 您希望達到哪種程度的可用性？99.5%、99.9% 還是 99.99%？
- 您需要多快完成容錯移轉？您的 RTO 和 RPO 是多少？
下列因素會影響復原時間，因此設定 RTO 和 RPO 時應考量這些因素：
- 偵測服務中斷
- 次要虛擬機器 (VM) 執行個體準備就緒
- 複製類型和備份頻率
- 儲存空間容錯移轉
- 資料庫復原時間
- 應用程式復原時間
MySQL HA 架構
在最基本的層級，資料層的 HA 包含下列項目：
- 識別來源節點發生故障的機制。
- 執行容錯移轉的程序，將副本節點升級為來源節點。
- 變更查詢路徑的程序，讓應用程式要求連上新的來源節點。
- (選用) 使用來源和副本節點還原原始拓撲的方法。
本文將探討下列三種 HA 架構：
除了基礎架構故障外，萬一發生區域服務中斷的罕見情況，這些架構都能協助盡量減少停機時間。您可以使用這些架構搭配網域名稱系統 (DNS) 變更，提供多區域高可用性，防範區域服務中斷，但本文討論的是可用區中斷。
使用區域永久磁碟的高可用性解決方案
資料層的 HA 一律會依賴某種資料複製方式。最簡單的複製方式就是無須管理。
透過 Compute Engine 的區域性永久磁碟儲存空間選項，您可以佈建區塊儲存空間裝置，在區域內的兩個可用區之間提供資料同步複製功能。地區永久磁碟是強大的基礎構成要素，可協助您在 Compute Engine 中實作高可用性服務。
下圖說明使用地區永久磁碟的 HA 架構。
如果來源節點 VM 執行個體因基礎架構故障或區域服務中斷而無法使用，您可以強制將地區永久磁碟連接至相同地區備份區域中的 VM 執行個體。
如要執行這項工作，您必須採取下列任一做法：
- 在備份區域中啟動另一個 VM 執行個體，存取共用的地區永久磁碟。
- 在備份區域中維護熱待命 VM 執行個體。熱待命 VM 執行個體是執行中的 VM 執行個體，與您使用的執行個體完全相同。連接地區永久磁碟後，即可啟動資料庫引擎。
如果及時發現資料服務中斷，強制連接作業通常會在不到一分鐘內完成，這表示可以達成以分鐘為單位的 RTO，且 RPO 為零。
如果貴商家可以容忍額外的停機時間，以便偵測及通報服務中斷，並手動執行容錯移轉，則不需要自動化程序。
如果 RTO 容許度較低，您可以自動偵測並執行容錯移轉程序。如果自動化這個架構，系統會變得更加複雜，因為容錯移轉和回復程序中有幾個需要考量的極端情況。如要進一步瞭解如何全自動實作這項架構，請參閱 Cloud SQL 高可用性設定。
優點
使用地區永久磁碟達成高可用性有下列優點：
這個架構可同時防範多種故障模式：來源伺服器區域基礎架構故障、單一區域的區塊儲存空間效能降低，或整個區域服務中斷。
由於地區永久磁碟提供持續且同步的區塊層級資料複製功能，並由 Google Cloud完全代管，因此不需要應用程式或資料庫層級的複製功能。地區永久磁碟會自動偵測錯誤和速度緩慢的情況、切換複製模式，並且補足僅複製到單一區域的資料。
如果主要區域發生儲存問題，地區永久磁碟會自動從次要區域執行讀取作業。這項作業可能會導致讀取延遲時間增加，但您的應用程式可以繼續運作，不需要任何手動操作。
注意事項
這項架構的限制與拓撲的單一區域性質有關，以及地區永久磁碟的下列固有限制：
- 地區永久磁碟只能掛接至一個資料庫。即使待命資料庫 VM 執行個體正在執行，該執行個體也無法用於提供資料庫讀取作業。不過，如果使用多重寫入模式的 Google Cloud Hyperdisk Balanced 高可用性磁碟，多個執行個體就能讀取及寫入同一個磁碟。如要進一步瞭解 Hyperdisk，請參閱「關於 Hyperdisk」。
- 這項架構背後的基礎技術只允許相同區域內的可用區進行複製。因此，如果只使用這種架構，就無法進行區域容錯移轉。
- 與區域永久磁碟相比，地區永久磁碟的寫入輸送量減半。確認輸送量限制在您可接受的範圍內。
- 地區永久磁碟的寫入延遲時間略高於區域永久磁碟。建議您測試工作負載，確認寫入效能符合需求。
- 發生故障事件並導致切換時，您需要強制將地區永久磁碟連接至待命區域 VM。強制連接作業通常會在 1 分鐘內執行，因此評估 RTO 時，請將這段時間納入考量。
- RTO 預估值必須考量強制連接地區永久磁碟所需的時間，以及 VM 檔案系統偵測熱連接磁碟所需的時間。
具有熱待命和見證節點的 HA
如要自動容錯移轉，必須採用不同的架構。其中一個選項是部署至少兩個資料庫節點的群組、設定資料庫非同步複製，以及啟動見證節點，確保在來源節點選舉期間能達到法定人數。
來源資料庫節點會處理寫入交易，並提供讀取查詢。資料庫複製程序會將變更傳輸至線上熱待機副本節點。
由於見證節點可以是小型虛擬機器，因此可提供低成本機制，確保群組多數成員可供來源節點選舉使用。
群組節點會持續評估其他群組節點的狀態。這些狀態檢查每隔幾秒就會使用的信號稱為「心跳」，因為這些信號用於評估其他群組節點的健康狀態。及時評估資料庫節點健康狀態非常重要，因為必須快速找出健康狀態不良的來源資料庫節點，才能啟動熱待機容錯移轉。
節點群組法定人數取決於投票元素數量，這些元素必須是有效叢集成員，叢集才能正常啟動或繼續執行。如要讓節點群組在來源資料庫節點選舉中達到法定人數，群組中大多數節點都必須參與。為防範核心分裂情況，多數節點規定可確保發生網路分割時，兩個投票群組不會同時有足夠的節點可投票。
群組多數由 (n+1)/2 個節點組成，其中 n 是群組中的節點總數。舉例來說，如果群組中有三個節點，至少要有兩個節點運作，才能選出來源節點。如果群組中有五個節點，則至少需要三個節點。
群組的大小會以節點的奇數為準，以免網路分割導致節點群組的子群組無法通訊。如果群組人數為偶數，兩個子群組的人數就更有可能少於多數。如果群組大小為奇數，其中一個子群組較有可能占多數，或兩個群組都不占多數。
下圖比較了正常的節點群組和效能降低的節點群組。
圖表顯示兩個節點群組：功能節點群組和降級節點群組。功能齊全且運作正常的節點群組有三個群組成員。在這個狀態下，來源和副本資料庫節點會提供預期用途。這個節點群組的必要仲裁數為兩個節點。
節點群組狀態降級表示基礎架構發生故障，導致來源節點心跳訊號不再傳送。這個狀態可能是因為來源資料庫節點執行個體故障，也可能是來源節點仍在執行。或者，網路分割可能會阻礙來源節點與群組中其他節點之間的通訊。
無論原因為何，副本和見證都會判斷來源節點不再處於健康狀態。此時，群組多數會進行來源節點選舉，判斷熱備援節點應成為來源節點，並啟動容錯移轉。
下圖顯示見證節點架構中的資料庫交易、複製和心跳流程。
在上圖中，這項高可用性架構依賴熱待機副本節點，在容錯移轉時快速開始處理正式版寫入作業。容錯移轉機制 (例如來源節點升級) 由群組中的資料庫節點執行。
如要實作這個架構，請考慮下列兩個專案：
- MySQL Group Replication 是 MySQL 的開放原始碼外掛程式，可協助建立高可用性拓撲。
- Galera Cluster 和 Percona XtraDB Cluster 是其他開放原始碼選項，可提供高可用性。
優點
熱待機架構的活動零件很少，部署方式簡單明瞭，且具備多項優點：
- 只要新增一個低成本的見證節點，即可提供全自動容錯移轉。
- 這個架構可有效解決長期基礎架構故障和暫時性故障 (例如因系統重新啟動而導致的故障)。
- 系統會提供多區域高可用性，但會有相關的複製延遲時間。
注意事項
系統會自動執行容錯移轉，但仍需執行下列作業：
- 您負責管理來源節點和副本節點之間的複製作業。
- 您負責管理見證節點。
- 您必須使用負載平衡器部署及管理連線路徑。
- 如果應用程式邏輯沒有變更 (不在本文討論範圍內)，您就無法將讀取作業導向副本節點。
使用 Orchestrator 和 ProxySQL 實現高可用性
如果結合開放原始碼元件、自動化調度管理工具和 ProxySQL，您就能建立架構，偵測中斷情形並自動將流量從受影響的來源節點容錯移轉至新升級的健全副本。
此外，您還可以將查詢作業透明地路由至適當的讀取或讀取/寫入節點，進而提升資料層的穩定狀態效能。
Orchestrator 是開放原始碼的 MySQL 複製拓撲管理工具和容錯移轉解決方案。這套軟體可讓您偵測、查詢及重構複雜的複製拓撲，並提供可靠的失敗偵測、智慧復原和升級功能。
ProxySQL 是一種開放原始碼的高效能資料庫，可做為 MySQL 的高可用性資料庫通訊協定感知 Proxy。ProxySQL 可擴充至數百萬個連線，並支援數十萬個後端伺服器。
下圖顯示 Orchestrator 和 ProxySQL 的合併架構。
如上圖所示，在這個架構中，資料庫繫結流量會由內部負載平衡器，路由至多餘的 ProxySQL 執行個體。這些執行個體會根據 ProxySQL 設定，將流量路由至可寫入或讀取的資料庫執行個體。
Orchestrator 提供下列失敗偵測和復原步驟：
- Orchestrator 判斷來源資料庫節點無法使用。
- 系統會查詢所有副本節點，以取得來源節點狀態的第二意見。
- 如果副本一致評估來源無法使用，就會進行容錯移轉。
- 如拓撲所定義，升級的節點會在容錯移轉期間成為新的來源節點。
- 容錯移轉完成後，Orchestrator 會根據拓撲，確保佈建正確數量的全新複寫節點。
區域 A 中來源資料庫與替代區域中的資料庫副本之間會持續進行複製作業，確保副本與任何寫入來源的資料保持同步。Orchestrator 會持續傳送心跳訊號，檢查來源和副本資料庫的健康狀態。協調器應用程式狀態會保留在另一個 Cloud SQL 資料庫中。如有拓撲變更需求，Orchestrator 也可以將指令傳送至資料庫。
容錯移轉完成後，ProxySQL 會將流量適當導向至新的來源和副本節點。服務會繼續使用負載平衡器的 IP 位址來處理資料層。虛擬 IP 位址會從先前的來源節點無縫切換至新的來源節點。
優點
架構元件和自動化功能可帶來下列優點：
- 這類架構使用的軟體提供各種可觀測性功能，包括複寫拓撲圖和查詢流量可視性。
- ProxySQL 和 Orchestrator 會協調運作，提供自動升級副本和容錯移轉功能。
- 副本升級政策完全可設定。與其他 HA 設定不同，您可以選擇在容錯移轉時將特定副本節點升級為來源。
- 容錯移轉後，系統會根據拓撲以宣告方式佈建新的副本。
- ProxySQL 會根據設定的政策，將讀取和寫入要求透明地路由至適當的副本和來源節點，因此可提供額外的負載平衡優勢。
注意事項
由於下列考量事項，這個架構會增加營運責任，並產生額外主機代管費用：
- Orchestrator 和 ProxySQL 都必須部署及維護。
- Orchestrator 需要另外的資料庫來維護狀態。
- 您必須設定 Orchestrator 和 ProxySQL，才能啟用高可用性，因此設定和部署作業會更加複雜。
此外，Orchestrator 不支援多來源複製，也不支援所有類型的平行複製，且無法與 Galera 或 Percona XtraDB 等叢集軟體合併使用。如要進一步瞭解目前的限制，請參閱 Orchestrator 常見問題。
後續步驟
- 瞭解 Cloud SQL 高可用性設定。
- 進一步瞭解使用地區永久磁碟的高可用性選項。
- 請參閱 MySQL Group Replication 說明文件。
- 瞭解 Galera Cluster 或相關的 Percona XtraDB Cluster。
- 參閱 Orchestrator 說明文件。
- 進一步瞭解 ProxySQL。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。