適用於 MariaDB 的 Azure 資料庫 中的高可用性
重要
適用於 MariaDB 的 Azure 資料庫 位於淘汰路徑上。 強烈建議您移轉至 適用於 MySQL 的 Azure 資料庫。 如需移轉至 適用於 MySQL 的 Azure 資料庫 的詳細資訊，請參閱 適用於 MariaDB 的 Azure 資料庫 發生什麼事？。
適用於 MariaDB 的 Azure 資料庫 服務適用於執行需要高運行時間的任務關鍵資料庫。 它會在下列期間提供高可用性：
- 已規劃的事件，例如使用者起始的調整計算作業。
- 非計劃性事件，例如基礎硬體、軟體或網路失敗。
適用於 MariaDB 的 Azure 資料庫 為運行時間提供財務支援的服務等級協定。 由於服務是以 Azure 架構為基礎所建置，因此您可以利用其功能來取得高可用性、備援和復原能力，而不需要設定任何其他元件。
適用於 MariaDB 的 Azure 資料庫中的元件
| 元件 | 描述 |
|---|---|
| MariaDB 資料庫伺服器 | 適用於 MariaDB 的 Azure 資料庫 提供資料庫伺服器的安全性、隔離、資源保護和快速重新啟動功能。 這些功能可協助作業，例如在中斷后調整和資料庫伺服器復原（以秒為單位）。 資料庫伺服器中的數據修改通常發生在資料庫交易的內容中。 所有資料庫變更都會以附加至資料庫伺服器之 Azure 儲存體 上的預先寫入記錄（ib_log檔案）形式同步記錄。 在資料庫 檢查點 程式期間，資料庫伺服器記憶體中的數據頁也會排清到記憶體。 |
| 遠端儲存體 | 所有 MariaDB 實體數據檔和記錄檔都會儲存在 Azure 儲存體 上，其會將三份數據復本儲存在區域內，以提供數據備援、可用性和可靠性。 儲存層與資料庫伺服器無關。 它可以從失敗的資料庫伺服器中斷連結，並在幾秒鐘內重新附加至新的資料庫伺服器。 Azure 儲存體持續監視任何記憶體錯誤。 如果偵測到區塊損毀，它會藉由具現化新的記憶體複本來自動修正問題。 |
| 閘道 | 網關會透過路由傳送所有用戶端連線到資料庫伺服器，作為資料庫 Proxy。 |
降低計劃性停機時間
適用於 MariaDB 的 Azure 資料庫 架構可在計劃性停機作業期間提供高可用性。
以下是計劃性維護的一些案例：
| 案例 | 描述 |
|---|---|
| 計算相應增加或相應減少 | 當您執行計算相應增加或相應減少作業時，適用於 MariaDB 的 Azure 資料庫 使用調整的計算組態布建新的資料庫伺服器。 在舊的資料庫伺服器上，服務可讓作用中的檢查點完成、清空用戶端連線，並取消任何未認可的交易。 服務接著會關閉舊的資料庫伺服器。 它會將記憶體與舊的資料庫伺服器中斷連結，並將記憶體附加至新的資料庫伺服器。 當用戶端應用程式重試連線或嘗試建立新的連線時，閘道會將連線要求導向至新的資料庫伺服器。 |
| 相應增加記憶體 | 相應增加記憶體是在線作業，不會中斷資料庫伺服器。 |
| 新的軟體部署 （Azure） | 新功能或 Bug 修正的推出會在服務的計畫性維護期間自動發生。 如需詳細資訊，請參閱 檔 並檢查您的 入口網站。 |
| 次要版本升級 | 適用於 MariaDB 的 Azure 資料庫 會自動將資料庫伺服器修補至 Azure 判斷的次要版本。 自動修補是服務計劃性維護的一部分。 其會在秒數方面產生短暫的停機時間，而且資料庫伺服器會自動以新的次要版本重新啟動。 如需詳細資訊，請參閱 檔 並檢查您的 入口網站。 |
非計劃性停機的風險降低
非計劃性停機可能會因為未預期的失敗而發生，包括基礎硬體錯誤、網路問題及軟體錯誤。 如果資料庫伺服器意外關閉，系統便會在幾秒鐘內自動佈建新的資料庫伺服器。 遠端儲存體會自動連結至新的資料庫伺服器。
MariaDB 引擎會使用預先寫入的記錄檔和資料庫檔案來執行復原作業，並開啟資料庫伺服器以允許用戶端連線。 未認可的交易會遺失，而且應用程式必須重試它們。
雖然您無法避免非計劃性的停機時間，但 適用於 MariaDB 的 Azure 資料庫 不需要人為介入，自動在資料庫伺服器和儲存層執行復原作業來減輕它。
非計劃性停機：失敗案例和服務復原
以下是兩個失敗案例，以及 適用於 MariaDB 的 Azure 資料庫 如何自動復原：
| 案例 | 自動復原 |
|---|---|
| 資料庫伺服器失敗 | 如果資料庫伺服器因為基礎硬體錯誤而關閉，適用於 MariaDB 的 Azure 資料庫 會卸載作用中聯機，並取消任何執行中的交易。 服務會自動部署新的資料庫伺服器，並將遠端資料記憶體附加至新的資料庫伺服器。 資料庫復原完成後，用戶端可以透過網關聯機到新的資料庫伺服器。 使用 MariaDB 資料庫的應用程式必須以偵測和重試已卸除的連線和失敗交易的方式建置。 當應用程式重試連線時，網關會以透明方式將連線重新導向至新建立的資料庫伺服器。 |
| 儲存體失敗 | 儲存體 相關問題，例如磁碟失敗或實體區塊損毀，不會影響應用程式。 因為數據會儲存在三個複本中，因此倖存的記憶體會提供數據的複本。 適用於 MariaDB 的 Azure 資料庫 會自動更正區塊損毀。 如果數據復本遺失，服務會自動建立新的數據複本。 |
以下是需要使用者動作才能復原的失敗案例：
| 案例 | 復原方案 |
|---|---|
| 區域失敗 | 區域失敗是罕見的事件。 不過，如果您需要保護區域失敗，您可以在其他區域中設定一或多個讀取複本，以進行災害復原。 如需詳細資訊，請參閱 這篇文章，以建立和管理讀取複本 。 如果發生區域層級失敗，您可以手動升級在另一個區域中設定為生產資料庫伺服器的讀取複本。 |
| 邏輯/用戶錯誤 | 從使用者錯誤中復原，例如意外卸除的數據表或不正確的更新數據，牽涉到執行 時間點復原。 此動作會還原並復原數據，直到發生錯誤之前的時間為止。 如果您想要只還原資料庫或特定數據表的子集，而不是資料庫伺服器中的所有資料庫，您可以在新的實例中還原資料庫伺服器、透過 mysqldump 匯出數據表，然後在 資料庫中還原 這些數據表。 |
摘要
適用於 MariaDB 的 Azure 資料庫 具有固有的高可用性功能，可協助保護您的資料庫免於常見的中斷。 它提供資料庫伺服器的快速重新啟動功能、備援記憶體，以及從閘道進行有效率的路由。 如需其他數據保護，您可以將備份設定為異地複寫，並在其他區域中部署讀取複本。