「適用於 MySQL 的 Azure 資料庫 - 彈性伺服器」的商務持續性概觀
適用於：
適用於 MySQL 的 Azure 資料庫 - 彈性伺服器
適用於 MySQL 的 Azure 資料庫彈性伺服器可實現商務持續性功能，在系統發生計劃性和非計劃性中斷時保護您的資料庫。 自動化備份和高可用性等功能可處理程度各不相同、有不同復原時間和資料遺失風險的錯誤保護。 當您建構應用程式以防範錯誤時，請考慮每個應用程式的復原時間目標 (RTO) 和復原點目標 (RPO)。 RTO 是停機時間容錯，RPO 則是資料庫服務中斷後的資料遺失容錯。
下表說明適用於 MySQL 的 Azure 資料庫彈性伺服器所提供的功能。
| 功能 | 說明 | 限制 |
|---|---|---|
| 備份與還原 | 伺服器會自動執行資料庫檔案的每日備份，並持續備份交易記錄。 備份可以保留為期 1 到 35 天的時間。 您可以將資料庫伺服器還原到備份保留期間內的任何時間點。 復原時間取決於要還原的資料大小加上用來復原記錄的時間。 如需詳細資訊，請參閱概念 - 備份與還原。 | 備份資料會留在區域內 |
| 本地備援備份 | 服務備份會自動且安全地儲存在區域內和相同可用性區域中的本地備援儲存體中。 本地備援備份會在主要區域中的單一實體位置內，複寫伺服器備份資料檔案三次。 本地備援備份儲存體可提供在指定一年中至少 99.999999999% (11 個九) 的物件耐久性。 如需詳細資訊，請參閱概念 - 備份與還原。 | 適用於所有區域 |
| 異地備援備份 | 服務備份可以在建立時設定為異地備援。 啟用異地備援會在主要區域的配對區域中複寫伺服器備份資料檔案，以提供區域性復原能力。 異地備援備份儲存體可提供在指定一年中至少 99.99999999999999% (16 個九) 的物件耐久性。 如需詳細資訊，請參閱概念 - 備份與還原。 | 適用於所有 Azure 配對區域 |
| 區域備援高可用性 | 您可在高可用性模式下部署此服務，以在某個區域內的兩個不同可用性區域中部署主要伺服器和待命伺服器。 區域備援高可用性可防範區域層級的失敗，也有助於在計劃性和非計劃性停機事件期間減少應用程式的停機時間。 主要伺服器中的資料會同步複寫到待命複本。 在任何停機事件期間，資料庫伺服器都會自動容錯移轉到待命複本。 如需詳細資訊，請參閱概念 - 高可用性。 | 一般用途和業務關鍵計算層會支援此功能。 僅適用於有多個區域 (zone) 的區域 (region)。 |
| 進階檔案共用 | 資料庫檔案會儲存在具有高耐久性和可靠性的 Azure 進階檔案共用中，以提供資料備援能力，其會將三個複本儲存在具有自動復原資料功能的可用性區域內。 如需詳細資訊，請參閱進階檔案共用。 | 資料會儲存在可用性區域內 |
降低計劃性停機的風險
以下是會產生停機的一些計劃性維護案例：
| 案例 | 處理 |
|---|---|
| 計算調整 (使用者) | 在執行計算調整作業時，系統會使用調整後的計算設定來佈建新的彈性伺服器。 在現有資料庫伺服器中，作用中的檢查點可允許完成、用戶端連線會清空、任何未認可的交易會取消，然後伺服器會關閉。 然後，儲存體會連結至新的伺服器，並啟動資料庫，以在接受用戶端連線之前，先視需要執行復原。 |
| 新的軟體部署 (Azure) | 服務在進行計劃性維護時會自動推出新功能或修正錯誤，而且您可以排定這些活動的發生時間。 如需詳細資訊，請參閱此文件，並查看您的入口網站 |
| 次要版本升級 (Azure) | 適用於 MySQL 的 Azure 資料庫彈性伺服器會自動將資料庫伺服器修補為 Azure 所決定的次要版本。 這是服務計劃性維護的一部分。 這會產生幾秒鐘短暫的停機時間，而且資料庫伺服器會自動以新的次要版本重新開機。 如需詳細資訊，請參閱此文件，並查看您的入口網站。 |
當彈性伺服器設定了區域備援高可用性時，彈性伺服器會先對待命伺服器執行作業，再於主要伺服器上執行作業，而不會進行容錯移轉。 如需詳細資訊，請參閱概念 - 高可用性。
非計劃性停機風險降低措施
系統可能會因為未預期的失敗 (包括基礎硬體故障、網路問題和軟體 Bug) 而發生非計劃性停機。 如果資料庫伺服器意外關閉，則在設定了高可用性 [HA] 的情況下，系統會啟動待命複本。 如果未設定，則會自動佈建新的資料庫伺服器。 雖然無法避免非計劃性停機，但彈性伺服器可不經人為介入就自動在資料庫伺服器層和儲存體層執行復原作業，藉此減輕停機問題。
非計劃性停機：失敗案例與服務復原
以下是一些非計劃性失敗案例和其復原程序：
| 案例 | 復原程序 [非 HA] | 復原程序 [HA] |
|---|---|---|
| 資料庫伺服器失敗 | 如果資料庫伺服器因為某些基礎硬體錯誤而關閉，則作用中的連線將會中斷，而且任何進行中的交易都會中止。 Azure 會嘗試重新啟動資料庫伺服器。 如果重新啟動成功，則會復原資料庫。 如果重新啟動失敗，則資料庫伺服器會嘗試在另一個實體節點上重新啟動。 復原時間 (RTO) 取決於各種因素，包括錯誤時的活動，例如大型交易，以及在資料庫伺服器啟動程式期間執行的復原量。 RPO 為零，因為已認可的交易應該不會遺失任何資料。 使用 MySQL 資料庫的應用程式必須以偵測到的方式建置，並重試中斷的連線和失敗的交易。 當應用程式重試時，連線會導向至新建立的資料庫伺服器。 其他可用的選項是從備份還原。 您可以從配對的區域使用 PITR 或異地還原。 PITR：RTO：不一定、RPO=0 秒 異地還原：RTO：不一定、RPO < 1 小時。 您也可以使用讀取複本來作為 DR 解決方案。 您可以停止複寫，讓讀取複本成為讀寫狀態 (獨立)，然後將應用程式流量重新導向至此資料庫。 在大部分情況下，RTO 為幾分鐘，而 RPO < 1 小時。 在某些情況下，RTO 和 RPO 會高很多，一切取決於網站之間的延遲、要傳輸的資料量，以及最重要的是主要資料庫寫入工作負載。 |
如果偵測到資料庫伺服器失敗或無法復原的錯誤，就會啟動待命資料庫伺服器，進而減少停機時間。 如需詳細資訊，請參閱 HA 概念頁面。 RTO 應該是 60 到 120 秒、RPO=0。 注意：復原程式 [非 HA] 的選項也適用於這裡。 |
| 儲存體失敗 | 應用程式不會看到任何儲存體相關問題的影響，例如：磁碟失敗或實體區塊損毀。 因為資料儲存於三個複本中，所以資料複本會由存留的儲存體提供。 區塊損毀會自動修正。 如果遺失資料複本，系統會自動建立新的資料複本。 在罕見或最糟的情況下，如果所有複本都損毀，我們可以使用異地還原 (配對區域)。 RPO 會 < 1 小時，RTO 則不一定。 您也可以使用讀取複本來作為 DR 解決方案，如上所述。 |
此案例的選項與復原程序 [非 HA] 的選項相同。 |
| 邏輯/使用者錯誤 | 使用者錯誤的復原 (例如意外卸載的資料表或不正確的更新資料) 牽涉到執行時間點復原 (PITR)，可將資料還原和復原到錯誤發生之前。 您可以在刪除伺服器後的五天內復原已卸除的彈性伺服器資源。 如需如何還原已刪除伺服器的詳細指南，[請參閱所記載的步驟] (../flexible-server/how-to-restore-dropped-server.md)。 若要在部署後避免伺服器資源遭到意外刪除或非預期的變更，系統管理員可以使用管理鎖定。 |
因為所有使用者作業也會複寫到待命伺服器，所以這些使用者錯誤不會受到高可用性功能的保護。 此案例的選項與復原程序 [非 HA] 的選項相同 |
| 可用性區域失敗 | 雖然這個事件很罕見，但如果您想要從區域層級的失敗復原，則可以執行從配對區域異地還原。 RPO 會是 < 1 小時，RTO 則不一定。 您也可以在其他可用性區域中建立複本，以使用讀取複本作為 DR 解決方案。 RTO\RPO 與上述的詳細資料相同。 |
如果您已啟用區域備援 HA，則彈性伺服器會自動容錯移轉至待命網站。 如需詳細資訊，請參閱 HA 概念。 RTO 應該是 60 到 120 秒、RPO=0。 其他可用的選項是從備份還原。 您可以從配對的區域使用 PITR 或異地還原。 PITR：RTO：不一定、RPO=0 秒 異地還原：RTO：不一定、RPO < 1 小時 注意：如果您已啟用相同的區域 HA，選項會與復原程式 [非 HA] 相同。 |
| 區域失敗 | 雖然這個事件很罕見，但如果您想要從區域層級的失敗復原，則可以執行資料庫復原，方法是使用相同訂用帳戶底下可用的最新異地備援備份來建立新的伺服器，以取得最新的資料。 新的彈性伺服器會部署到所選的區域。 還原所花費的時間取決於先前的備份以及要復原的交易記錄數目。 在大部分情況下，RPO 會 < 1 小時，RTO 則不一定。 | 此案例的選項與復原程序 [非 HA] 的選項相同。 |
需求和限制
區域資料落地
依預設，適用於 MySQL 的 Azure 資料庫彈性伺服器不會將客戶資料移動或儲存到其部署所在的區域外。 不過，客戶可選擇性地啟用異地備援備份或設定跨區域複寫，以便將資料儲存在另一個區域中。