災害復原指引 - Azure SQL 資料庫

  • 發行項

適用於：Azure SQL Database

Azure SQL 資料庫提供至少 99.99% 的業界領先高可用性保證，以支援任務關鍵性，以及需要隨時可用的各種應用程式。 Azure SQL 資料庫也能夠擁有關鍵商務持續性功能，可讓您在發生區域性中斷事件發生時執行快速災害復原。 本文包含在應用程式部署前檢閱的重要資訊。

雖然我們持續努力提供高可用性，但有時候 Azure SQL 資料庫服務會產生中斷而導致資料庫無法使用，因而影響您的應用程式。 當服務監視偵測的問題會造成廣泛連線錯誤、失敗或效能問題時，服務會自動宣告中斷，以通知您。

服務中斷

如果發生 Azure SQL 資料庫服務中斷的事件，您將能夠在下列位置看到與中斷相關的其他詳細資料：

  • Azure 入口網站橫幅

    如果識別到您的訂用帳戶受到影響，Azure 入口網站通知中的服務問題將會中斷通知：

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • [說明 + 支援] 或 [支援 + 疑難排解]

    當您從說明 + 支援或支援 + 疑難排解建立支援票證時，會有任何影響您資源問題的相關資訊。 選取 [檢視中斷詳細資料] 以取得詳細資訊和影響摘要。 新增支援要求頁面中也會有警示。

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • 服務健全狀況

    Azure 入口網站中的服務健康狀態頁面包含全域 Azure 資料中心狀態的相關資訊。 在 Azure 入口網站的搜尋列中搜尋「服務健康狀態」，然後在 [作用中事件] 類別中檢視服務問題。 您也可以在 [說明] 功能表下任何資源的資源健康狀態頁面中檢視個別資源的健全狀況。 以下為服務健康狀態頁面的範例螢幕擷取畫面，其中包含東南亞作用中服務問題的相關資訊：

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • 電子郵件通知

    如果您已設定警示，當服務中斷影響您的訂用帳戶和資源時，會收到來自 azure-noreply@microsoft.com 的電子郵件通知。 電子郵件本文一般開頭會是「活動記錄警示...由 Azure 訂用帳戶的服務問題觸發...」。 如需有關服務健康狀態警示的詳細資訊，請參閱使用 Azure 入口網站在 Azure 服務通知上接收活動記錄警示。

在中斷期間啟動災害復原的時機

如果服務中斷影響應用程式資源，請考慮下列動作進程：

  • Azure 團隊會努力儘快還原服務可用性，但需視根本原因而言，有時可能需要數小時。 如果您的應用程式可以容忍長時間停機，您可以等待復原完成。 在此情況下，您不需要採取任何動作。 請在 [說明] 功能表下任何資源的資源健康狀態頁面中檢視個別資源的健全狀況。 請參閱資源健康狀態頁面，以取得有關中斷的更新和最新資訊。 復原區域之後，就會還原您應用程式的可用性。

  • 復原到另一個 Azure 區域可能需要變更應用程式連接字串，或使用 DNS 重新導向，且可能會導致永久資料遺失。 因此，只有在中斷期間接近應用程式的復原時間目標 (RTO) 時，才會執行災害復原。 當應用程式部署到生產環境時，您應該定期監視應用程式的健康狀態，並判斷只有在從應用層到資料庫發生長時間連線失敗時，才需要復原。 根據您的應用程式對停機的容錯和潛在商務責任，您可以決定是否要等候服務自行復原或起始災害復原。

中斷復原指引

如果區域中的 Azure SQL 資料庫中斷已延長一段時間，且會影響應用程式的服務等級協定 (SLA)，請考慮遵循下列步驟：

容錯移轉 (不會遺失資料) 到異地複寫的次要伺服器

如果已啟用作用中異地複寫或容錯移轉群組，請檢查主要和次要資料庫資源狀態是否在 Azure 入口網站中為在線。 若是如此，則主資料庫和次要資料庫的資料平面狀況良好。 使用 Azure 入口網站、T-SQL、PowerShell 或 Azure CLI 起始作用中異地複寫或容錯移轉群組，至次要區域的容錯移轉。

注意

容錯移轉在切換角色之前，需要完整資料同步處理，且不會造成資料遺失。 根據服務中斷類型，不保證容錯移轉不會遺失資料，但值得作為第一個復原選項進行嘗試。

若要起始容錯移轉，請使用下列連結：

技術 方法 步驟
作用中異地複寫 PowerShell 透過 PowerShell 容錯移轉至異地複寫次要
T-SQL 透過 T-SQL 容錯移轉至異地複寫次要
容錯移轉群組 Azure CLI 透過 Azure CLI 容錯移轉至次要伺服器
Azure 入口網站 透過 Azure 入口網站容錯移轉至次要伺服器
PowerShell 透過 PowerShell 容錯移轉至次要伺服器

強制容錯移轉 (可能遺失資料) 到異地複寫的次要伺服器

如果容錯移轉未正常完成，且發生錯誤，或主資料庫狀態不是在線，請仔細考慮移至次要區域可能發生資料遺失的強制容錯移轉。

若要起始強制容錯移轉，請使用下列連結：

技術 方法 步驟
作用中異地複寫 Azure CLI 透過 Azure CLI 強制容錯移轉到異地複寫次要伺服器
Azure 入口網站 透過 Azure 入口網站強制容錯移轉到異地複寫次要伺服器
PowerShell 透過 PowerShell 強制容錯移轉至異地複寫次要
T-SQL 透過 T-SQL 強制容錯移轉至異地複寫次要
容錯移轉群組 Azure 入口網站 透過 Azure 入口網站強制容錯移轉到次要伺服器，但選擇強制容錯移轉。
Azure CLI 透過 Azure CLI 強制容錯移轉至次要伺服器 但使用 --allow-data-loss
PowerShell 透過 PowerShell 強制容錯移轉至次要伺服器 但使用 -AllowDataLoss

異地復原

如果您尚未啟用作用中異地複寫或容錯移轉群組，則最後一個方式就是使用異地還原從中斷復原。 異地還原會使用異地複寫備份作為來源。 您可以從最新的異地複寫備份中，在任何 Azure 區域的任何邏輯伺服器上還原資料庫。 即使中斷導致資料庫或整個區域無法存取，您仍然可以要求異地還原。

如需透過 Azure CLI、Azure 入口網站、PowerShell 或 REST API 要求異地還原的詳細資訊，請參閱 Azure SQL 資料庫的異地還原。

在復原之後設定資料庫

如果您使用異地容錯移轉或異地復原來從中斷復原，您必須確定已正確設定新資料庫的連接，才能繼續執行正常的應用程式功能。 以下工作檢查清單可協助您準備產生復原的資料庫。

重要

建議您定期鑽研災害復原策略，以確認應用程式容錯，以及復原程式的所有作業層面。 應用程式基礎結構的其他層級可能需要重新設定。 如需復原架構步驟的詳細資訊，請檢閱 Azure SQL Database 高可用性和災害復原檢查清單。

更新連接字串

  • 如果您使用作用中異地複寫或異地復原，您必須確定已正確設定新資料庫的連接，才能繼續執行正常的應用程式功能。 因為復原的資料庫位於不同的伺服器，所以您必須更新應用程式的連接字串以指向該伺服器。 如需變更連接字串的詳細資訊，請參閱 連線庫的適當開發語言。
  • 如果您使用容錯移轉群組從中斷復原，並在您的應用程式連接字串中使用讀寫和唯讀接聽程式，則不需要採取進一步的動作，因為會自動連線導向至新的主要複本。

設定防火牆規則

您需要確認伺服器和資料庫上設定的防火牆規則符合主要伺服器與主要資料庫上設定的防火牆規則。 如需詳細資訊，請參閱 如何：進行防火牆設定 (Azure SQL Database)。

設定登入和資料庫使用者

建立登入，新主要伺服器的 master 資料庫中必須有這些登入，並確保這些登入在 master 資料庫中有適當的權限 (如果有的話)。 如需詳細資訊，請參閱 災害復原後的 Azure SQL Database 安全性。

設定遙測警示

您必須確定現有的警示規則設定已更新，才能對應至新的主要資料庫和不同的伺服器。 如需有關資料庫警示規則的詳細資訊，請參閱接收警示通知和追蹤服務健全狀況。

啟用稽核

如果需要稽核才能存取您的資料庫，則您必須在資料庫復原之後啟用稽核。 如需詳細資訊，請參閱 Azure SQL Azure SQL Database 的稽核。

下一步