使用分散式可用性群組將 SQL Server 遷移至 AWS - AWS 方案指引

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

使用分散式可用性群組將 SQL Server 遷移至 AWS

由 Praveen Marthala (AWS) 建立

Summary

Microsoft SQL Server Always On 可用性群組為 SQL Server 提供高可用性 (HA) 和災難復原 (DR) 解決方案。可用性群組包含接受讀取/寫入流量的主要複本,以及最多八個接受讀取流量的次要複本。可用性群組是在具有兩個或多個節點的 Windows Server 容錯移轉叢集 (WSFC) 上設定。

Microsoft SQL Server Always On 分散式可用性群組提供解決方案,可在兩個獨立的 WFSCs之間設定兩個不同的可用性群組。屬於分散式可用性群組的可用性群組不必位於相同的資料中心。一個可用性群組可以是內部部署,另一個可用性群組可以是位於不同網域中 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上的 Amazon Web Services (AWS) Cloud。 

此模式概述使用分散式可用性群組將屬於現有可用性群組一部分的內部部署 SQL Server 資料庫遷移至 SQL Server,並在 Amazon EC2 上設定可用性群組的步驟。透過遵循此模式,您可以將資料庫遷移至 AWS 雲端,並在切換期間將停機時間降至最低。在切換之後,AWS 會立即提供高度可用的資料庫。您也可以使用此模式,將基礎作業系統從現場部署變更為 AWS,同時保留相同版本的 SQL Server。

先決條件和限制

先決條件

  • 作用中的 AWS 帳戶

  • AWS Direct Connect 或 AWS Site-to-Site VPN

  • 在 AWS 的兩個節點上安裝的相同 SQL Server 版本

產品版本

  • SQL Server 2016 版及更新版本

  • SQL Server Enterprise Edition

架構

來源技術堆疊

  • 內部部署中具有 Always On 可用性群組的 Microsoft SQL Server 資料庫

目標技術堆疊

  • AWS 雲端上 Amazon EC2 上具有 Always On 可用性群組的 Microsoft SQL Server 資料庫

遷移架構

內部部署和 AWS 上可用群組中具有同步複寫的 SQL Server。

術語

  • WSFC 1 – 內部部署的 WSFC

  • WSFC 2 – AWS 雲端上的 WSFC

  • AG 1 – 第一個可用性群組,位於 WSFC 1 中

  • AG 2 – 第二個可用性群組,位於 WSFC 2 中

  • SQL Server 主要複本 – AG 1 中的節點,被視為所有寫入的全域主要節點

  • SQL Server 轉送器 – AG 2 中的節點,以非同步方式從 SQL Server 主要複本接收資料

  • SQL Server 次要複本 – AG 1 或 AG 2 中從主要複本或轉送器同步接收資料的節點

工具

  • AWS Direct Connect – AWS Direct Connect 會透過標準乙太網路光纖纜線將您的內部網路連結至 AWS Direct Connect 位置。透過此連線,您可以直接建立與公有 AWS 服務的虛擬介面,繞過網路路徑中的網際網路服務供應商。

  • Amazon EC2 – Amazon Elastic Compute Cloud (Amazon EC2) 在 AWS 雲端中提供可擴展的運算容量。您可以使用 Amazon EC2 視需要啟動任意數量或任意數量的虛擬伺服器,也可以向外擴展或向內擴展。

  • AWS Site-to-Site VPN – AWS Site-to-Site VPN 支援建立site-to-site虛擬私有網路 (VPN)。您可以設定 VPN 在 AWS 上啟動的執行個體與您自己的遠端網路之間傳遞流量。

  • Microsoft SQL Server Management Studio – Microsoft SQL Server Management Studio (SSMS) 是管理 SQL Server 基礎設施的整合環境。它提供使用者介面和一組工具,其中包含與 SQL Server 互動的豐富指令碼編輯器。

史詩

任務描述所需的技能

在 AWS 上建立 WSFC。

在具有兩個 HA 節點的 Amazon EC2 執行個體上建立 WSFC 2。您將使用此容錯移轉叢集在 AWS 上建立第二個可用性群組 (AG 2)。

系統管理員、SysOps 管理員

在 WSFC 2 上建立第二個可用性群組。

使用 SSMS,在 WSFC 2 中的兩個節點上建立 AG 2。WSFC 2 中的第一個節點將做為轉送器。WSFC 2 中的第二個節點將充當 AG 2 的次要複本。

在此階段,AG 2 中沒有可用的資料庫。這是設定分散式可用性群組的起點。

DBA、開發人員

在 AG 2 上建立沒有復原選項的資料庫。

備份內部部署可用性群組 (AG 1) 上的資料庫。 

在沒有復原選項的情況下,將資料庫還原至 AG 2 的轉寄站和次要複本。還原資料庫時,請為資料庫資料檔案和日誌檔案指定磁碟空間足夠的位置。

在此階段,資料庫處於還原狀態。它們不屬於 AG 2 或分散式可用性群組,而且不會同步。

DBA、開發人員
任務描述所需的技能

在 AG 1 上建立分散式可用性群組。

若要在 AG 1 上建立分散式可用性群組,請使用 CREATE AVAILABILITY GROUP搭配 DISTRIBUTED選項。

  1. 使用 AG 1 和 AG 2 的LISTENER_URL端點地址。

  2. 對於 AVAILABILITY-MODE,如果有的話,請使用 ASYNCHRONOUS_COMMIT 來避免網路延遲。這不會影響資料庫的效能。

  3. 對於 FAILOVER_MODE,請使用 MANUAL。這是唯一可與分散式可用性群組搭配使用的可用性模式。

  4. 若要在 AG 2 上手動還原資料庫,並對大型資料庫有更多控制權,請MANUAL針對 使用 SEEDING_MODE

DBA、開發人員

在 AG 2 上建立分散式可用性群組。

若要在 AG 2 上建立分散式可用性群組,請使用 ALTER AVAILABILITY GROUP搭配 DISTRIBUTED選項。

  1. 使用 AG 1 和 AG 2 的LISTENER_URL端點地址。

  2. 對於 AVAILABILITY-MODE,如果有的話,請使用 ASYNCHRONOUS_COMMIT 來避免網路延遲。這不會影響資料庫的效能。

  3. 對於 FAILOVER_MODE,請使用 MANUAL。這是唯一可與分散式可用性群組搭配使用的可用性模式。

  4. 若要在 AG 2 上手動還原資料庫,並對大型資料庫有更多控制權,請MANUAL針對 使用 SEEDING_MODE

分散式可用性群組是在 AG 1 和 AG 2 之間建立。

AG 2 中的資料庫尚未設定為參與從 AG 1 到 AG 2 的資料流程。

DBA、開發人員

將資料庫新增至 AG 2 上的轉送器和次要複本。

使用 ALTER DATABASE 搭配 AG 2 上轉送器和次要複本中的 SET HADRAVAILABILITY GROUP選項,將資料庫新增至分散式可用性群組。 

這會在 AG 1 和 AG 2 上的資料庫之間啟動非同步資料流程。 

全域主要會進行寫入、同步傳送資料至 AG 1 上的次要複本,以及非同步傳送資料至 AG 2 上的轉送器。AG 2 上的轉送器會將資料同步傳送至 AG 2 上的次要複本。

DBA、開發人員
任務描述所需的技能

使用 DMVs和 SQL Server 日誌。

使用動態管理檢視 (DMVs) 和 SQL Server 日誌,監控兩個可用群組之間的資料流程狀態。 

值得監控的 DMVs 包括 sys.dm_hadr_availability_replica_statessys.dm_hadr_automatic_seeding

對於轉送器同步狀態,請在轉送器的 SQL Server 日誌中監控同步狀態

DBA、開發人員
任務描述所需的技能

停止所有流向主要複本的流量。

停止傳入至 AG 1 中主要複本的流量,以便在資料庫上不會發生寫入活動,且資料庫已準備好進行遷移。

應用程式擁有者、開發人員

變更 AG 1 上分散式可用性群組的可用性模式。

在主要複本上,將分散式可用性群組的可用性模式設定為同步。 

將可用性模式變更為同步後,資料會從 AG 1 中的主要複本同步傳送至 AG 2 中的轉寄站。

DBA、開發人員

檢查兩個可用群組中的 LSNs。

檢查 AG 1 和 AG 2 中的最後一個日誌序號 (LSNs)。由於 AG 1 的主要複本中沒有發生寫入,因此資料會同步,且兩個可用性群組的最後一個 LSNs 應相符。

DBA、開發人員

將 AG 1 更新為次要角色。

當您將 AG 1 更新為次要角色時,AG 1 會失去主要複本角色,且不接受寫入,且兩個可用群組之間的資料流程會停止。

DBA、開發人員
任務描述所需的技能

手動容錯移轉至 AG 2。

在 AG 2 中的轉送器上,變更分散式可用性群組以允許資料遺失。由於您已檢查並確認 AG 1 和 AG 2 上的最後一個 LSNs 相符,因此資料遺失並非問題。

當您允許 AG 2 中的轉送器遺失資料時,AG 1 和 AG 2 的角色會變更:

  • AG 2 會成為具有主要複本和次要複本的可用性群組。

  • AG 1 會成為具有轉送器和次要複本的可用性群組。

DBA、開發人員

變更 AG 2 上分散式可用性群組的可用性模式。

在 AG 2 的主要複本上,將可用性模式變更為非同步。

這會將資料從 AG 2 移動到 AG 1,從同步移動到非同步。此步驟是必要的,以避免 AG 2 和 AG 1 之間的網路延遲,如果有的話,而且不會影響資料庫的效能。

DBA、開發人員

開始將流量傳送至新的主要複本。

更新連線字串以使用 AG 2 上的接聽程式 URL 端點,將流量傳送至資料庫。

AG 2 現在接受寫入並將資料傳送至 AG 1 中的轉寄站,以及將資料傳送至 AG 2 中自己的次要複本。資料從 AG 2 非同步移動到 AG 1。

應用程式擁有者、開發人員
任務描述所需的技能

在 AG 2 上捨棄分散式可用性群組。

監控遷移的計劃時間量。然後捨棄 AG 2 上的分散式可用性群組,以移除 AG 2 和 AG 1 之間的分散式可用性群組設定。這會移除分散式可用性群組組態,而且從 AG 2 到 AG 1 的資料流程會停止。 

此時,AG 2 可在 AWS 上高度使用,主要複本採用寫入,次要複本則位於相同的可用性群組中。

DBA、開發人員

停用內部部署伺服器。

在屬於 AG 1 的 WSFC 1 中停用內部部署伺服器。

系統管理員、SysOps 管理員

相關資源