共用方式為

高可用性和災害復原檢查清單 - Azure SQL 資料庫

  • 發行項

適用於：Azure SQL 資料庫

Azure SQL 資料庫服務會自動確保所有資料庫都在線上、狀況良好，並且持續努力達成已發佈的 SLA。

本指南為您可以主動採取的步驟提供了詳細評論，包含最大化可用性、確保復原，以及為 Azure 中斷最好準備等步驟。 本指南適用於 Azure SQL Database 的所有購買模型和服務層級。

可用性檢查清單

以下是以最大化可用性的建議設定：

高可用性檢查清單

以下是達到高可用性的建議組態：

  • 啟用可供資料庫或彈性集區使用的區域備援，以確保區域失敗時的復原能力。

災害復原檢查清單

雖然 Azure SQL 資料庫會自動維護可用性，但當中斷的影響橫跨整個區域時，即便具有高可用性（區域備援）的執行個體也可能無法保證復原性。 區域性 Azure SQL 資料庫中斷時，可能需要由您起始災害復原。

若要為災害復原做好最佳準備，請遵循下列建議：

  • 啟用資料庫群組的容錯移轉群組。
    • 在應用程式連接字串中使用讀寫和唯讀接聽程式端點，讓應用程式自動連線到目前主要的伺服器和資料庫。
    • 將容錯移轉原則設定為客戶管理。
  • 除容錯移轉群組之外，您可啟用作用中異地複寫，以便在不同的 Azure 區域中具有可讀取的次要資料庫。
  • 確定異地次要資料庫是以與主要資料庫相同的服務層級、 計算層 （已佈建或無伺服器）和計算大小（DTU 或虛擬核心）建立。
  • 擴大時，先擴大異地次要資料庫，再擴大主要資料庫。
  • 縮小時，則反轉順序：先縮小主要資料庫，再縮小次要資料庫。
  • 災害復原在本質上旨在活動主要和次要區域之間的資料非同步複寫。 若比起較高的提交延遲，要讓資料可用性的優先順序更高，請考慮在提交交易之後立即呼叫 sp_wait_for_database_copy_sync 預存程序。 呼叫 sp_wait_for_database_copy_sync 會封鎖呼叫執行緒，直到最後認可的交易已傳輸和強行寫入次要資料庫交易記錄為止。
  • 使用主資料庫上 sys.dm_geo_replication_link_status 動態管理檢視 (DMV) 的 replication_lag_sec 資料行，來監視復原點目標 (RPO) 的延遲。 其中會顯示主要資料庫上認可交易之間的延遲 (以秒為單位)，並將其強行寫入次要資料庫上的交易記錄。 例如，如果某個時間點的延隔時間是一秒，如果主要資料庫在這段時間受到中斷的影響並起始異地容錯移轉，則在上一秒認可的交易將會遺失。
  • 如果無法啟用容錯移轉群組或作用中異地複寫，請考慮將備份記憶體備援選項設定為異地備援備份記憶體，以使用異地還原功能。
  • 經常規劃和執行災害復原演練，可讓您在實際發生中斷時較不會手忙腳亂。

準備針對中斷的次要複本

若要使用作用中異地複寫、容錯移轉群組或異地還原，成功復原到另一個資料區域，您必須在另一個區域中準備次要 Azure SQL 資料庫邏輯伺服器。 必要時，這個次要伺服器可能會成為新的主伺服器。 您也應該有書面資料，清楚記載復原步驟並實際進行測試，以確保復原能夠順暢。 這些準備步驟包括︰

  • 若要進行異地復原，請先找出位在另一個區域，且要成為新主要伺服器的伺服器。 如果您的主要區域有 配對的區域，通常會使用配對的區域作為次要區域。 如此一來，您通常會減少複寫和異地還原作業的延遲。
  • 決定要如何將使用者重新導向到新的主要伺服器。 重新導向使用者可以透過手動變更應用程式連接字串或 DNS 項目來完成。 如果您已啟用容錯移轉群組，並在應用程式連接字串中使用了讀寫及唯讀接聽程式，則不需要採取進一步的動作，因為容錯移轉後，系統會自動將連線導向到新的主要伺服器。
  • 找出並選擇性地定義使用者要存取新的主要資料庫時，所需的防火牆規則。
  • 找出 (或是建立) 登入，新主要伺服器的 master 資料庫中必須有這些登入，且須確保這些登入在 master 資料庫中有適當的權限 (如果有的話)。 如需詳細資訊，請參閱災害復原後的 Azure SQL Database 安全性。
  • 找出需要更新的警示規則，以便對應到新的主伺服器。
  • 記錄目前主要伺服器的稽核組態，並在次要伺服器設定相同組態。

相關內容