適用於 MySQL 的 Azure 資料庫中的高可用性
適用於：
適用於 MySQL 的 Azure 資料庫 - 單一伺服器
重要
適用於 MySQL 的 Azure 資料庫 單一伺服器位於淘汰路徑上。 強烈建議您升級至適用於 MySQL 的 Azure 資料庫彈性伺服器。 如需移轉至適用於 MySQL 的 Azure 資料庫彈性伺服器的詳細資訊，請參閱適用於 MySQL 的 Azure 資料庫單一伺服器會發生什麼事？
適用於 MySQL 的 Azure 資料庫服務提供高層級可用性保證，且具有執行時間 99.99% 的費用補償服務等級協定 (SLA)。 適用於 MySQL 的 Azure 資料庫會在計劃性事件 (例如使用者起始的規模計算作業) 期間及非計劃性事件 (例如基礎硬體、軟體或網路失敗) 期間，提供高可用性。 適用於 MySQL 的 Azure 資料庫可以從大部分的重大情況下快速復原，確保使用此服務時幾乎不會造成任何應用程式停機。
適用於 MySQL 的 Azure 資料庫適合執行需要高運作時間的任務關鍵資料庫。 此服務以 Azure 架構為基礎，具有固有的高可用性、備援和復原功能，可降低計劃性和非計劃性中斷的資料庫停機時間，而且不需要您設定任何其他元件。
適用於 MySQL 的 Azure 資料庫中的元件
| 元件 | 說明 |
|---|---|
| MySQL 資料庫伺服器 | 適用於 MySQL 的 Azure 資料庫可為資料庫伺服器提供安全性、隔離、資源防護和快速重新啟動功能。 這些功能有助於在發生中斷後的 60-120 秒內 (視資料庫的交易活動而定)，加快執行規模調整和資料庫伺服器復原等作業。 資料庫伺服器中的資料修改通常會發生在資料庫交易的內容中。 所有資料庫變更都會以預先寫入記錄 (ib_log) 的形式來同步記錄在 Azure 儲存體 (其與資料庫伺服器連結)。 在資料庫的檢查點處理期間，資料庫伺服器記憶體中的資料頁也會排清到儲存體。 |
| 遠端儲存體 | 所有 MySQL 實體資料檔案和記錄檔都會儲存在 Azure 儲存體上，其結構為在區域內儲存三份資料複本，以確保資料具有備援、可用性和可靠性。 儲存層也獨立於資料庫伺服器。 其可以從失敗的資料庫伺服器中斷連結，並在 60 秒內重新連結至新的資料庫伺服器。 此外，Azure 儲存體會持續監視任何儲存體錯誤。 如果偵測到區塊損毀，則會藉由具現化新的儲存體複本來自動修正。 |
| 閘道 | 閘道可作為資料庫 Proxy，用於將所有用戶端連線路由至資料庫伺服器。 |
降低計劃性停機的風險
適用於 MySQL 的 Azure 資料庫結構可在計劃性停機作業期間提供高可用性。
以下是一些計劃性維護案例：
| 案例 | 說明 |
|---|---|
| 計算擴大/縮小 | 當使用者執行計算擴大/縮小作業時，就會使用調整的計算設定來佈建新的資料庫伺服器。 在舊的資料庫伺服器中，作用中的檢查點可允許完成、用戶端連線會清空、任何未認可的交易會取消，然後伺服器會關閉。 接著，儲存體會與舊的資料庫伺服器中斷連結，並連結至新的資料庫伺服器。 當用戶端應用程式重試連線，或嘗試建立新的連線時，閘道會將連線要求導向至新的資料庫伺服器。 |
| 擴大儲存體 | 擴大儲存體是線上作業，不會中斷資料庫伺服器。 |
| 新的軟體部署 (Azure) | 新功能推出或錯誤修正會在服務的計劃性維護過程中自動發生。 如需詳細資訊，請參閱此文件，並查看您的入口網站。 |
| 次要版本升級 | 適用於 MySQL 的 Azure 資料庫會自動將資料庫伺服器修補為 Azure 所決定的次要版本。 這是服務計劃性維護的一部分。 在計劃性維護期間，資料庫伺服器可能會重新啟動或容錯移轉，這可能會導致終端使用者的資料庫伺服器短暫無法使用。 適用於 MySQL 的 Azure 資料庫伺服器會在容器中執行，因此資料庫伺服器的重新啟動通常會在 60-120 秒內快速完成。 整個計劃性維護事件 (包括每個伺服器的重新啟動) 都會受到工程小組密切監控。 伺服器容錯移轉時間取決於資料庫復原時間，如果容錯移轉時伺服器上有大量交易活動，可能會導致資料庫上線的時間較長。 若要避免重新啟動時間拉長，建議您在計劃性維護事件期間避免任何長時間執行的交易 (大量載入)。 如需詳細資訊，請參閱此文件，並查看您的入口網站。 |
非計劃性停機風險降低措施
系統可能會因為未預期的失敗 (包括基礎硬體故障、網路問題和軟體錯誤) 而發生非計劃性停機。 如果資料庫伺服器意外關閉，新的資料庫伺服器便會在 60-120 秒內自動佈建。 遠端儲存體會自動連結至新的資料庫伺服器。 MySQL 引擎會使用 WAL 和資料庫檔案來執行復原作業，並開啟資料庫伺服器讓用戶端得以連線。 未認可的交易會遺失，應用程式必須重試這些交易。 雖然無法避免非計劃性停機，但適用於 MySQL 的 Azure 資料庫可不經人為介入就自動在資料庫伺服器層和儲存體層執行復原作業，藉此減輕停機問題。
非計劃性停機：失敗案例與服務復原
以下是一些失敗案例，以及適用於 MySQL 的 Azure 資料庫如何自動復原：
| 案例 | 自動復原 |
|---|---|
| 資料庫伺服器失敗 | 如果資料庫伺服器因為某些基礎硬體錯誤而關閉，則作用中的連線將會中斷，而且任何進行中的交易都會中止。 新的資料庫伺服器會自動部署，而遠端資料儲存體會連結至新的資料庫伺服器。 完成資料庫復原後，用戶端即可透過閘道連線至最新的資料庫伺服器。 使用 MySQL 資料庫的應用程式必須以偵測到的方式建置，並重試中斷的連線和失敗的交易。 當應用程式重試時，閘道會以透明方式將連線重新導向至新建立的資料庫伺服器。 |
| 儲存體失敗 | 應用程式不會看到任何儲存體相關問題的影響，例如：磁碟失敗或實體區塊損毀。 由於資料儲存成 3 個複本，因此資料複本會由存留的儲存體提供。 區塊損毀會自動校正。 如果遺失資料複本，則會自動建立新的資料複本。 |
以下是需要使用者動作才能復原的一些失敗案例：
| 案例 | 復原計畫 |
|---|---|
| 區域失敗 | 區域失敗是罕見的事件。 不過，如果您需要保護而不受區域失敗影響，則可以在其他區域中設定一或多個讀取複本來用於災害復原 (DR)。 (如需詳細資料，請參閱有關建立和管理讀取複本的此文章)。 發生區域層級的失敗時，您可以手動將其他區域上設定的讀取複本升階為生產資料庫伺服器。 |
| 邏輯/使用者錯誤 | 使用者錯誤的復原 (例如意外卸載的資料表或不正確的更新資料) 牽涉到執行時間點復原 (PITR)，可將資料還原和復原到錯誤發生之前。 如果您只想還原資料庫子集或特定資料表，而不是資料庫伺服器中的所有資料庫，則可以在新執行個體中還原資料庫伺服器，透過 mysqldump 匯出資料表，然後使用 restore 將這些資料表還原到資料庫。 |
摘要
適用於 MySQL 的 Azure 資料庫提供資料庫伺服器的快速重新啟動功能、備援儲存體，以及來自閘道的有效路由。 如需其他資料保護，您可以將備份設定為異地複寫，也可以在其他區域中部署一個或多個讀取複本。 透過固有的高可用性功能，適用於 MySQL 的 Azure 資料庫可保護您的資料庫避免最常見的中斷情況，並提供領先業界且具有財務補償的 99.99% 運作時間 SLA。 所有這些可用性和可靠性功能，讓 Azure 成為了執行任務關鍵性應用程式的理想平台。
下一步
- 了解 Azure 區域
- 了解如何處理暫時性連線錯誤
- 了解如何使用讀取複本來複寫資料