設定 SQL Server 災害復原

本文說明如何協助保護應用程式的 SQL Server 後端。 您可以使用 SQL Server 商務持續性和災害復原 (BCDR) 技術和 Azure Site Recovery 的組合來執行此動作。

開始之前,請確定您瞭解 SQL Server 災害復原功能。 這些功能包括:

  • 容錯移轉叢集
  • Always On 可用性群組
  • 資料庫鏡像
  • 記錄傳送
  • 使用中的地理複寫
  • 自動容錯移轉群組

結合 BCDR 技術與 Site Recovery

選擇BCDR技術來復原SQL Server 實例,應根據您的復原時間目標 (RTO) 和恢復點目標 (RPO) 需求,如下表所述。 結合 Site Recovery 與所選技術的故障轉移作業,以協調整個應用程式的復原。

部署類型 BCDR 技術 SQL Server 的預期 RTO SQL Server 的預期 RPO
Azure 基礎結構即服務 (IaaS) 虛擬機 (VM) 或內部部署上的 SQL Server。 AlwaysOn 可用性群組 將次要複本設為主要複本所花費的時間。 因為複寫至次要複本是異步的,因此會有一些數據遺失。
Azure IaaS VM 或內部部署上的 SQL Server。 容錯轉移叢集 (Always On FCI) 在節點之間故障轉移所花費的時間。 因為Always On FCI使用共用記憶體,因此故障轉移時可以使用記憶體實例的相同檢視。
Azure IaaS VM 或內部部署上的 SQL Server。 資料庫鏡像 (高效能模式) 強制服務所花費的時間,此服務會使用鏡像伺服器做為暖待命伺服器。 復寫是異步的。 鏡像資料庫可能會稍微落後主體資料庫。 延隔時間通常很小。 但如果主體或鏡像伺服器的系統負載過重,它可能會變得很大。

記錄傳送可以是資料庫鏡像的補充。 這是異步資料庫鏡像的有利替代方案。
Azure 上的 SQL 即平臺即服務 (PaaS)。

此部署類型包含單一資料庫和彈性集區。
作用中異地複寫 觸發故障轉移後的30秒。

當其中一個輔助資料庫啟用故障轉移時,所有其他次要資料庫會自動連結至新的主資料庫。
5 秒的 RPO。

主動式異地復寫使用 SQL Server 的 Always On 技術。 它會使用快照集隔離,以異步方式將主資料庫上認可的交易復寫至輔助資料庫。

保證次要數據永遠不會有部分交易。
在 Azure 上使用作用中異地複寫設定為 PaaS 的 SQL。

此部署類型包含受控實例、彈性集區和單一資料庫。
自動容錯移轉群組 一小時的 RTO。 5 秒的 RPO。

自動故障轉移群組提供作用中異地復寫之上的群組語意。 但使用相同的異步復寫機制。
Azure IaaS VM 或內部部署上的 SQL Server。 使用 Azure Site Recovery 進行複寫 RTO 通常少於 15 分鐘。 若要深入瞭解,請閱讀 Site Recovery 所提供的 RTO SLA。 應用程式一致性的一小時和5分鐘的當機一致性。 如果您要尋找較低的 RPO,請使用其他 BCDR 技術。

注意

當您協助使用 Site Recovery 保護 SQL 工作負載時,有一些重要考慮:

  • Site Recovery 與應用程式無關。 Site Recovery 可協助保護在支援的操作系統上部署的任何 SQL Server 版本。 若要深入瞭解,請參閱 復寫機器復原 的支援矩陣。
  • 您可以選擇使用 Site Recovery 進行 Azure、Hyper-V、VMware 或實體基礎結構的任何部署。 請遵循本文 結尾的指引,瞭解如何使用 Site Recovery 協助保護 SQL Server 叢集
  • 請確定計算機上觀察到的數據變更率位於 Site Recovery 限制。 變更速率是以每秒寫入位元組為單位來測量。 針對執行 Windows 的機器,您可以選取 [任務管理器] 中的 [效能] 索引卷標來檢視此變更率。 觀察每個磁碟的寫入速度。
  • Site Recovery 支援在 儲存空間直接存取 上複寫故障轉移叢集實例。 若要深入瞭解,請參閱如何啟用 儲存空間直接存取 複寫

當您將 SQL 工作負載移轉至 Azure 時,建議您套用 Azure 上 SQL Server 的效能指導方針 虛擬機器

應用程式的災害復原

Site Recovery 透過復原方案協助,協調整個應用程式的測試故障轉移和故障轉移。

有一些必要條件可確保您的復原方案根據您的需求完全自定義。 任何 SQL Server 部署通常需要 Active Directory 部署。 它也需要應用層的連線能力。

步驟 1:設定 Active Directory

在次要復原站台中設定 Active Directory,讓 SQL Server 能夠正常執行。

  • 小型企業:您有一些應用程式和內部部署網站的單一域控制器。 如果您想要故障轉移整個月臺,請使用 Site Recovery 複寫。 此服務會將域控制器複寫至次要數據中心或 Azure。
  • 中型到大型企業:您可能需要設定其他域控制器。
    • 如果您有大量應用程式、具有 Active Directory 樹系,而且想要依應用程式或工作負載故障轉移,請在次要數據中心或 Azure 中設定另一個域控制器。
    • 如果您使用 Always On 可用性群組復原至遠端月臺,請在次要網站或 Azure 中設定另一個域控制器。 此域控制器用於復原的 SQL Server 實例。

本文中的指示假設域控制器可在次要位置使用。 若要深入瞭解,請參閱協助使用 Site Recovery 保護 Active Directory 的程式

步驟 2:確保與其他層的連線能力

在目標 Azure 區域中執行資料庫層之後,請確定您已與應用程式和 Web 層連線。 請事先採取必要步驟,以驗證與測試故障轉移的連線。

若要瞭解如何設計應用程式以進行連線考慮,請參閱下列範例:

步驟 3:與 AlwaysOn 互通、主動式異地複寫和自動故障轉移群組

BCDR 技術 AlwaysOn、主動式異地復寫和自動故障轉移群組具有在目標 Azure 區域中執行的 SQL Server 次要複本。 應用程式故障轉移的第一個步驟是將此複本指定為主要複本。 此步驟假設您已經有次要域控制器。 如果您選擇進行自動故障轉移,可能不需要此步驟。 只有在資料庫故障轉移完成之後,才能故障轉移您的 Web 和應用層。

注意

如果您已協助使用 Site Recovery 保護 SQL 機器,您只需要建立這些機器的復原群組,並在復原方案中新增其故障轉移。

使用應用程式和 Web 層虛擬機建立復原方案 。 下列步驟示範如何新增資料庫層的故障轉移:

  1. 匯入腳本,以在 Resource Manager 虛擬機傳統虛擬機中故障轉移 SQL 可用性群組。 將腳本匯入 Azure 自動化 帳戶。

    Button to deploy the Resource Manager template to Azure.

  2. 將 ASR-SQL-FailoverAG 指令碼新增為復原計畫第一個群組的前置動作。

  3. 依照腳本中提供的指示來建立自動化變數。 此變數提供可用性群組的名稱。

步驟 4:進行測試故障轉移

某些 BCDR 技術,例如 SQL Always On 原生不支援測試故障轉移。 只有在使用這類技術時,才建議使用下列方法

  1. 在裝載 Azure 中可用性群組複本的 VM 上設定 Azure 備份

  2. 觸發復原計劃測試故障轉移之前,請先從上一個步驟中建立的備份復原 VM。

    Screenshot showing window for restoring a configuration from Azure Backup

  3. 在從備份還原的 VM 中強制仲裁

  4. 將接聽程式的IP位址更新為測試故障轉移網路中可用的位址。

    Screenshot of rules window and IP address properties dialog

  5. 使接聽程式連線。

    Screenshot of window labeled Content_AG showing server names and statuses

  6. 請確定故障轉移網路中負載平衡器有一個IP位址,從對應至每個可用性群組接聽程式的前端IP位址池,以及後端集區中的SQL Server VM。

    Screenshot of window titled

    Screenshot of window titled

  7. 在稍後的復原群組中,新增應用層的故障轉移,然後新增此復原方案的Web層。

  8. 執行復原計劃的測試故障轉移,以測試應用程式的端對端故障轉移。

執行故障轉移的步驟

在步驟 3 中新增文稿並在步驟 4 中驗證之後,您可以執行在步驟 3 中建立的復原計劃故障轉移。

應用程式和 Web 層的故障轉移步驟應該在測試故障轉移和故障轉移復原方案中相同。

如何協助保護 SQL Server 叢集

針對執行 SQL Server Standard 版本或 SQL Server 2008 R2 的叢集,建議您使用 Site Recovery 複寫來協助保護 SQL Server。

Azure 至 Azure 和內部部署至 Azure

Site Recovery 不會在復寫至 Azure 區域時提供客體叢集支援。 SQL Server Standard 版本也不會提供低成本的災害復原解決方案。 在此案例中,建議您保護 SQL Server 叢集到主要位置的獨立 SQL Server 實例,並在次要位置復原它。

  1. 在主要 Azure 區域或內部部署網站上設定另一個獨立 SQL Server 實例。

  2. 將 實例設定為做為您想要協助保護之資料庫的鏡像。 以高安全性模式設定鏡像。

  3. 在 AzureHyper-VVMware VM 和實體伺服器上的主要站臺上設定 Site Recovery。

  4. 使用 Site Recovery 複寫將新的 SQL Server 實例複寫至次要月臺。 因為它是高安全性鏡像複本,它會與主要叢集同步處理,但會使用 Site Recovery 複寫進行複寫。

    Image of a standard cluster that shows the relationship and flow among a primary site, Site Recovery, and Azure

容錯回復考慮

針對 SQL Server Standard 叢集,非計劃性故障轉移之後的容錯回復需要 SQL Server 備份和還原。 這項作業是從鏡像實例到原始叢集,並重新建立鏡像。

常見問題集

搭配 Site Recovery 使用時,SQL Server 如何獲得授權?

SQL Server 的 Site Recovery 複寫涵蓋在軟體保證災害復原權益之下。 此涵蓋範圍適用於所有 Site Recovery 案例:內部部署至 Azure 災害復原和跨區域 Azure IaaS 災害復原。 如需詳細資訊,請參閱 Azure Site Recovery 定價

Site Recovery 是否會支援我的 SQL Server 版本?

Site Recovery 與應用程式無關。 Site Recovery 可協助保護在支援的操作系統上部署的任何 SQL Server 版本。 如需詳細資訊,請參閱 復寫機器復原 的支援矩陣。

ASR 是否可與 SQL 事務複製搭配使用?

由於 ASR 使用檔案層級複製,SQL 無法保證相關聯 SQL 複製拓撲中的伺服器在 ASR 故障轉移時會同步。 這可能會導致logreader和/或散發代理程式因為 LSN 不符而失敗,這可能會中斷複寫。 如果您在複製拓撲中故障轉移發行者、散發者或訂閱者,則需要重建複寫。 建議重新 初始化 SQL Server 的訂用帳戶。

下一步