這份文件說明幾種架構，可為 Cloud de Confiance by S3NS上的 MySQL 部署作業提供高可用性 (HA)。高可用性是衡量系統在底層基礎架構故障時的復原能力。本文中的高可用性是指單一雲端區域內 MySQL 叢集的可用性。
本文適用於資料庫管理員、雲端架構師和 DevOps 工程師，說明如何提高整體系統正常運作時間，進而提升 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 包含下列項目：
- 用於識別來源節點發生故障的機制。
- 執行容錯移轉的程序，將副本節點升級為來源節點。
- 變更查詢路徑的程序，讓應用程式要求傳送至新的來源節點。
- (選用) 使用來源和副本節點回復原始拓撲的方法。
本文將探討下列三種高可用性架構：
除了基礎架構故障外，萬一發生區域服務中斷的罕見情況，這些架構也能盡可能縮短停機時間。您可以使用這些架構搭配網域名稱系統 (DNS) 變更，提供多區域高可用性，防範區域性服務中斷，但本文討論的是可用區中斷。
使用區域永久磁碟的高可用性
資料層的 HA 一律會依賴某種資料複製方式。最簡單的複製方式就是無須管理。
透過 Compute Engine 的區域永久磁碟儲存空間選項，您可以佈建區塊儲存空間裝置，在區域內的兩個可用區之間提供資料同步複製功能。區域永久磁碟是強大的基礎構成元素，可協助您在 Compute Engine 中實作高可用性服務。
下圖說明使用地區永久磁碟的 HA 架構。
如果來源節點 VM 執行個體因基礎架構故障或區域服務中斷而無法使用，您可以強制將地區永久磁碟連接至相同區域備份區域中的 VM 執行個體。
如要執行這項工作，請採取下列任一做法：
- 在備份區域中啟動另一個 VM 執行個體，存取共用的地區永久磁碟。
- 在備份區域中維護熱待命 VM 執行個體。熱待命 VM 執行個體是執行中的 VM 執行個體，與您使用的執行個體完全相同。連接地區永久磁碟後，即可啟動資料庫引擎。
如果及時發現資料服務中斷，強制連接作業通常會在不到一分鐘內完成，這表示可以達成以分鐘為單位的 RTO，且 RPO 為零。
如果貴商家可以容忍額外的停機時間，以便偵測及通報服務中斷，並手動執行容錯移轉，則不需要自動化程序。
如果 RTO 容許度較低，可以自動執行偵測和容錯移轉程序。如果自動化這個架構，系統會變得更加複雜，因為容錯移轉和回復程序中有幾個需要考量的極端情況。如要進一步瞭解如何全自動實作這項架構，請參閱「Cloud SQL 高可用性設定」。
優點
使用地區永久磁碟達成高可用性有下列優點：
這個架構可同時防範多種故障模式：來源伺服器可用區基礎架構故障、單一可用區的區塊儲存空間效能降低，或整個可用區服務中斷。
由於地區永久磁碟提供持續且同步的區塊層級資料複製功能，並由 Cloud de Confiance全面管理，因此不需要應用程式或資料庫層級的複製功能。地區永久磁碟會自動偵測錯誤和速度緩慢的情況、切換複寫模式，並且補足僅複製到單一可用區的資料。
如果主要區域發生儲存問題，地區永久磁碟會自動從次要區域執行讀取作業。這項作業可能會導致讀取延遲時間增加，但應用程式可以繼續運作，不必手動操作。
注意事項
這項架構的限制與拓撲的單一區域性質有關，以及區域永久磁碟的下列固有限制：
- 地區永久磁碟只能掛接至一個資料庫。 即使待命資料庫 VM 執行個體正在執行，該執行個體也無法用於提供資料庫讀取服務。不過，如果使用 Google Cloud Hyperdisk Balanced High Availability，並將磁碟設為多重寫入模式，多個執行個體就能讀取及寫入同一個磁碟。如要進一步瞭解 Hyperdisk，請參閱「關於 Hyperdisk」。
- 這項架構背後的基礎技術只允許相同區域內的可用區進行複製作業。因此，如果只使用這個架構，就無法進行區域容錯移轉。
- 與區域永久磁碟相比，地區永久磁碟的寫入輸送量減半。確認處理量限制在可接受的範圍內。
- 地區永久磁碟的寫入延遲時間略高於區域永久磁碟。建議您測試工作負載，確認寫入效能符合需求。
- 發生故障事件並導致轉換時，您需要強制將地區永久磁碟連接至待命可用區 VM。強制連接作業通常會在 1 分鐘內執行，因此評估 RTO 時，請將這段時間納入考量。
- RTO 預估值必須考量強制連接地區永久磁碟所需的時間，以及 VM 檔案系統偵測熱連接磁碟所需的時間。
高可用性，具備熱待命和見證節點
如要自動容錯移轉，則需要不同的架構。其中一個選項是部署至少兩個資料庫節點的群組、設定資料庫非同步複製，以及啟動見證節點，確保在來源節點選舉期間能達到法定人數。
來源資料庫節點會處理寫入交易，並提供讀取查詢。資料庫複製程序會將變更傳輸至線上熱待機副本節點。
由於見證節點可以是小型虛擬機器，因此可提供低成本機制，確保群組多數成員可用於來源節點選舉。
群組節點會持續評估其他群組節點的狀態。這些狀態檢查每隔幾秒就會使用的信號稱為「心跳」，因為這些信號用於評估其他群組節點的健康狀態。及時評估資料庫節點健康狀態非常重要，因為必須快速找出健康狀態不良的來源資料庫節點，才能啟動熱待機容錯移轉。
節點群組仲裁是由投票元素數量決定，這些元素必須是有效叢集成員，叢集才能正常啟動或繼續執行。如要讓節點群組在來源資料庫節點選舉中達到法定人數，群組中大多數節點都必須參與。為防範核心分裂情況，多數節點規定可確保在發生網路分割時，兩個投票群組不會同時有足夠的節點可投票。
群組多數由 (n+1)/2 個節點組成，其中 n 是群組中的節點總數。舉例來說，如果群組中有三個節點，至少要有兩個節點運作，才能選出來源節點。如果群組中有五個節點，則至少需要三個節點。
群組的大小為奇數個節點，以免網路分割導致節點群組的子群組無法通訊。如果群組人數為偶數，兩個子群組的人數就更有可能少於多數。如果群組大小為奇數，其中一個子群組較有可能獲得多數票，或兩者皆未獲得多數票。
下圖比較了正常的節點群組和效能降低的節點群組。
圖表顯示兩個節點群組：功能節點群組和降級節點群組。功能齊全且運作正常的節點群組有三個群組成員。在這個狀態下，來源和副本資料庫節點會提供預期的用途。這個節點群組的必要仲裁數為兩個節點。
節點群組狀態降級表示基礎架構發生故障，導致來源節點心跳訊號不再傳送。這個狀態可能是因為來源資料庫節點執行個體故障，或是來源節點仍在執行。或者，網路分割可能會導致來源節點與群組中的其他節點無法通訊。
無論原因為何，副本和見證都會判斷來源節點不再處於健康狀態。此時，群組多數會進行來源節點選舉，判斷熱備援節點應成為來源節點，並啟動容錯移轉。
下圖顯示見證節點架構中的資料庫交易、複製和心跳流程。
在上圖中，這項高可用性架構依賴熱待機副本節點，在容錯移轉時快速開始處理正式環境寫入作業。容錯移轉機制 (例如來源節點升級) 由群組中的資料庫節點執行。
如要實作這項架構，請考慮下列兩個專案：
- MySQL Group Replication 是 MySQL 的開放原始碼外掛程式，可協助建立高可用性拓撲。
- Galera Cluster 和 Percona XtraDB Cluster 是其他開放原始碼選項，可提供高可用性。
優點
熱待命架構的活動零件很少，部署方式簡單明瞭，且具有下列優點：
- 只要新增一個低成本的見證節點，即可提供全自動容錯移轉功能。
- 這個架構可有效解決長期基礎架構故障和暫時性故障 (例如因系統重新啟動而導致的故障)。
- 並提供多區域高可用性，但會出現相關的複製延遲時間。
注意事項
系統會自動執行容錯移轉，但仍需完成下列作業：
- 您負責管理來源節點和副本節點之間的複製作業。
- 您負責管理見證節點。
- 您必須使用負載平衡器部署及管理連線路徑。
- 如果沒有變更應用程式邏輯 (不在本文討論範圍內)，您就無法將讀取作業導向副本節點。
透過 Orchestrator 和 ProxySQL 實現高可用性
如果結合開放原始碼元件「自動化調度管理程式」和「ProxySQL」ProxySQL，您就能建立架構，偵測中斷情形並自動將流量從受影響的來源節點容錯移轉至新升級的健全副本。
此外，您還可以將查詢透明地路由至適當的讀取或讀寫節點，進而提升穩態資料層效能。
Orchestrator 是開放原始碼的 MySQL 複製拓撲管理工具和容錯移轉解決方案。這套軟體可讓您偵測、查詢及重構複雜的複製拓撲，並提供可靠的故障偵測、智慧復原和升級功能。
ProxySQL 是一種開放原始碼的高效能資料庫，可做為 MySQL 的高可用性資料庫通訊協定感知 Proxy。ProxySQL 可擴充至數百萬個連線，涵蓋數十萬個後端伺服器。
下圖顯示 Orchestrator 和 ProxySQL 的合併架構。
如上圖所示，在這個架構中，資料庫繫結流量會由內部負載平衡器，路由至多餘的 ProxySQL 執行個體。這些執行個體會根據 ProxySQL 設定，將流量路由至可寫入或讀取的資料庫執行個體。
Orchestrator 提供下列失敗偵測和復原步驟：
- Orchestrator 判斷來源資料庫節點無法使用。
- 系統會查詢所有副本節點，以取得來源節點狀態的第二意見。
- 如果副本一致評估來源無法使用，就會進行容錯移轉。
- 如拓撲所定義，升級的節點會在容錯移轉期間成為新的來源節點。
- 容錯移轉完成後，Orchestrator 會根據拓撲，確保佈建正確數量的全新複寫節點。
區域 A 中的來源資料庫與替代區域中的資料庫副本之間會持續進行複製，確保副本與任何寫入來源的資料保持同步。調度器會持續傳送心跳訊號，檢查來源和副本資料庫的健康狀態。協調器應用程式狀態會保留在另一個 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 Architecture Center。