共用方式為

高可用性和災害復原檢查清單 - 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 會封鎖呼叫執行緒，直到最後認可的交易已傳送並寫入次要資料庫的交易記錄為止。
  • 使用主資料庫上的 replication_lag_sec 資料行來監控與復原點目標 (RPO) 相關的延遲，這可透過 sys.dm_geo_replication_link_status 動態管理檢視 (DMV) 來實現。 DMV 會顯示從主要資料庫提交的交易到在次要資料庫的交易日志中持久化之間的延遲時間（以秒為單位）。 假設某個時間點的延遲是一秒，如果此時主要資料庫受到中斷的影響並啟動異地容錯移轉程序，那麼在最後一秒內提交的交易將會遺失。
  • 如果無法啟用故障轉移群組或主動式異地複寫，請考慮將 備份儲存體備援選項設為異地備援備份儲存選項，以便進行 Azure SQL Database 的異地還原。
  • 經常規劃和執行災害復原演練，可讓您在實際發生中斷時較不會手忙腳亂。

準備用於中斷的備用系統

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

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

相關內容