使用分布式可用性组将 SQL Server 迁移至 AWS - AWS Prescriptive Guidance
总结先决条件和限制架构工具操作说明相关资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用分布式可用性组将 SQL Server 迁移至 AWS

由 Praveen Marthala (AWS) 编写

来源：本地 SQL Server

目标：SQL Server on EC2

R 类型：更换主机

环境：PoC 或试点

技术：数据库；迁移

工作负载：Microsoft

Amazon Web Services：Amazon EC2

总结

Microsoft SQL Server Always On 可用性组为 SQL Server 提供了高可用性 (HA) 和灾难恢复 (DR) 解决方案。可用性组由一个接受读/写流量的主副本，和最多八个接受读取流量的辅助副本组成。可用性组是在具有两个或更多节点的 Windows 服务器失效转移群集 (WSFC) 上配置。

Microsoft SQL Server Always On 分布式可用性组提供了在两个独立的 WFSC 之间配置两个独立的可用性组的解决方案。属于分布式可用性组的可用性组不必位于同一数据中心。一个可用性组可以位于本地，另一个可用性组可以位于另一个不同域 Amazon Web Services (AWS) Cloud 上的 Amazon Elastic Compute Cloud (Amazon EC2)实例上。 

此模式概述了使用分布式可用性组，将属于现有可用性组的本地 SQL Server 数据库迁移至具有在 Amazon EC2 上设置可用组的 SQL Server 的步骤。通过遵循该模式，您可以将数据库迁移至 Amazon Web Services Cloud 中，同时最大限度地减少割接期间的停机时间。割接后，这些数据库立即在 AWS 上具有高可用性。您还可使用此模式将底层操作系统从本地更改为 AWS，同时保持相同版本的 SQL Server。

先决条件和限制

先决条件

  • 一个有效的 Amazon Web Services account

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

  • 安装在本地和 AWS 上的两个节点上相同版本 SQL Server

产品版本

  • SQL Server 版本 2016 和更高版本

  • SQL Server 企业版

架构

源技术堆栈

  • 本地具有 Always On 可用性组的 Microsoft SQL Server 数据库

目标技术堆栈

  • Amazon Web Services Cloud 上 Amazon EC2 上具有 Always On 可用性组的 Microsoft SQL Server 数据库

迁移架构

术语

  • WSFC 1 — WSFC 本地

  • WSFC 2 — Amazon Web Services Cloud 上的 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 位置。通过此连接，您可以创建直接连接到公有 Amazon Web Services 的虚拟接口，从而绕过网络路径中的互联网服务提供商。

  • Amazon EC2 – Amazon Elastic Compute Cloud (Amazon EC2) 在 Amazon Web Services Cloud 中提供可扩展的计算容量。您可根据需要使用 Amazon EC2 启动任意数量的虚拟服务器，您可以横向扩展或横向缩减。

  • AWS 站点到站点 VPN — AWS 站点到站点 VPN 支持创建虚拟专用网络 (VPN)。 site-to-site 您可以将 VPN 配置为在 AWS 上启动的实例和您自己的远程网络之间传递流量。

  • Microsoft SQL Server Management Studio – Microsoft SQL Server Management Studio (SSMS) 是一个用于管理 SQL Server 基础设施的集成环境。它提供了用户界面和一组工具，其中包含与 SQL Server 交互的丰富脚本编辑器。

操作说明

任务描述所需技能
在 AWS 上创建 WSFC。

在 Amazon EC2 实例上创建 WSFC 2，包含两个可用于 HA 的节点。您将使用此失效转移群集在 AWS 上创建第二可用性组 (AG 2)。

系统管理员、 SysOps 管理员
在 WSFC 2 上创建第二可用性组。

使用 SSMS 在 WSFC 2 中的两个节点创建 AG 2。WSFC 2 中的第一节点将充当转发器。WSFC 2 中的第二节点将作为 AG 2 的辅助副本。

在此阶段，AG 2 中没有可用数据库。其为设置分布式可用性组的起点。

数据库管理员、开发人员
在 AG 2 上创建无恢复选项的数据库。

备份本地可用性组 (AG 1) 数据库。 

在没有恢复选项的情况下，将数据库还原至 AG 2 的转发器和辅助副本。还原数据库时，请指定足够磁盘空间，以存放数据库数据文件和日志文件。

在该阶段，数据库处于还原状态。它们不是 AG 2 或分布式可用性组的一部分，也非同步。

数据库管理员、开发人员
任务描述所需技能
在 AG 1 上创建分布式可用性组。

要在 AG 1 上创建分布式可用性组，请使用带DISTRIBUTED选项的CREATE AVAILABILITY GROUP。

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

  2. 对于AVAILABILITY-MODE，用于ASYNCHRONOUS_COMMIT避免网络延迟（如有）。这并非影响数据库的性能。

  3. 对于 FAILOVER_MODE，请使用 MANUAL。这是唯一适用于分布式可用性组的可用性模式。

  4. 要在 AG 2 上手动还原数据库并对较大的数据库进行更多控制，请使用SEEDING_MODE的MANUAL。

数据库管理员、开发人员
在 AG 2 上创建分布式可用性组。

要在 AG 2 上创建分布式可用性组，请通过DISTRIBUTED选项使用ALTER AVAILABILITY GROUP。

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

  2. 对于AVAILABILITY-MODE，用于ASYNCHRONOUS_COMMIT避免网络延迟（如有）。这并非影响数据库的性能。

  3. 对于 FAILOVER_MODE，请使用 MANUAL。这是唯一适用于分布式可用性组的可用性模式。

  4. 要在 AG 2 上手动还原数据库并对较大的数据库进行更多控制，请使用SEEDING_MODE的MANUAL。

分布式可用性组在 AG 1 和 AG 2 间创建。

AG 2 中的数据库尚未配置为：参与从 AG 1 到 AG 2 的数据流。

数据库管理员、开发人员
将数据库添加至 AG 2 上的转发器和辅助副本。

在 AG 2 的转发器和辅助副本中使用SET HADRAVAILABILITY GROUP选项的ALTER DATABASE将数据库添加到分布式可用性组。 

这将启动 AG 1 和 AG 2 上的数据库间的异步数据流。 

全局主服务器接受写入，将数据同步发送至 AG 1 上的辅助副本，并异步向 AG 2 上的转发器发送数据。AG 2 上的转发器将数据同步发送至 AG 2 上的辅助副本。

数据库管理员、开发人员
任务描述所需技能
使用 DMV 和 SQL Server 日志。

使用动态管理视图 (DMV) 和 SQL Server 日志监控两个可用性组间的数据流状态。 

值得监控的 DMV 包括sys.dm_hadr_availability_replica_states和sys.dm_hadr_automatic_seeding。

要了解转发器同步的状态，在转发器上的 SQL Server 日志中监控同步状态。

数据库管理员、开发人员
任务描述所需技能
停止所有流向主副本流量。

在 AG 1 中阻止主副本传入流量，这样数据库上就不会发生写入活动，数据库就可以迁移了。

应用程序所有者、开发人员
更改 AG 1 上的分布式可用性组的可用性模式。

在主副本上，将分布式可用性组可用性模式设置为同步。 

将可用性模式更改为同步模式后，数据将从 AG 1 主副本同步发送至 AG 2 中的转发器。

数据库管理员、开发人员
检查两个可用性组的 LSN。

检查 AG 1 和 AG 2 中最后一个日志序列号 (LSN)。由于 AG 1 的主副本中未发生写入操作，因此该数据已同步，两个可用性组的最后一个 LSN 应匹配。

数据库管理员、开发人员
将 AG 1 更新至辅助角色。

当您将 AG 1 更新至辅助角色时，AG 1 将失去主副本角色并且不接受写入，两个可用性组之间的数据流将停止。

数据库管理员、开发人员
任务描述所需技能
手动故障转移至 AG 2。

在 AG 2 的转发器，更改分布式可用性组以允许数据丢失。由于您已经检查并确认了 AG 1 和 AG 2 上最后一个 LSN 是否匹配，因此不需担心数据丢失。

当您允许 AG 2 中转发器的数据丢失时，AG 1 和 AG 2 的角色会发生变化：

  • AG 2 成为包含主副本和辅助副本的可用性组。

  • AG 1 成为带有转发器和辅助副本的可用性组。

数据库管理员、开发人员
更改 AG 2 上的分布式可用性组的可用性模式。

在 AG 2 主副本上，将可用性模式更改为异步。

这会将数据从 AG 2 移动至 AG 1、从同步移动更改为异步移动。此步骤是为了避免 AG 2 和 AG 1 间的网络延迟（如有），并且不会影响数据库的性能。

数据库管理员、开发人员
开始向新主副本发送流量。

更新连接字符串，以使用 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 上具有高可用性，主副本需写入，辅助副本位于同一个可用性组中。

数据库管理员、开发人员
停用本地服务器。

停用属于 AG 1 的 WSFC 1 中的本地服务器。

系统管理员、 SysOps 管理员

相关资源