共用方式為

高可用性和災害復原檢查清單 - 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 安全性。
  • 找出需要更新的警示規則，以便對應到新的主伺服器。
  • 記錄目前主要伺服器的稽核組態，並在次要伺服器設定相同組態。

相關內容