教程：使用迁移服务预览版从 Amazon Aurora PostgreSQL 在线迁移到 Azure Database for PostgreSQL

Azure 门户提供简单直观的基于向导的体验，可引导你完成迁移。 遵循本教程中所述的步骤，可以将数据库无缝转移到 Azure Database for PostgreSQL 灵活服务器，并利用其强大的功能和可伸缩性。

若要使用 Azure 门户进行迁移，首先请配置迁移任务，连接到源和目标，然后执行迁移。

配置迁移任务

该迁移服务在 Microsoft Azure 门户中提供了一种基于向导的简单体验。 下面介绍如何开始：

1. 打开 Web 浏览器并转到门户。 输入凭据登录。 默认视图是服务仪表板。

2. 转到你的 Azure Database for PostgreSQL 灵活服务器目标。

3. 在灵活服务器的“概述”选项卡的左侧菜单中，向下滚动到“迁移”并将其选中。

   

4. 选择“创建”按钮，以从 Amazon Aurora 迁移到 Azure Database for PostgreSQL 灵活服务器。 第一次使用迁移服务时，将会显示一个空网格，并提示你开始第一次迁移。

   

   如果已创建到 Azure Database for PostgreSQL 目标的迁移，则网格将包含有关尝试的迁移的信息。

5. 选择“创建”按钮。 然后，完成基于向导的一系列选项卡中的操作，以创建从 PostgreSQL 源实例到此 Azure Database for PostgreSQL 目标的迁移。

安装

第一个选项卡是“设置”选项卡，用户需在此提供迁移详细信息（例如迁移名称、源类型）以启动迁移。

• “迁移名称”是每个到此灵活服务器目标的迁移的唯一标识符。 此字段仅接受字母数字字符，不接受除连字符 (-) 之外的任何特殊字符。 名称不能以连字符开头，并且对于目标服务器应是唯一的。 到同一灵活服务器目标的两个迁移不能同名。

• 源服务器类型 - 根据 PostgreSQL 源，可选择相应的源类型，例如基于云的 PostgreSQL 服务、本地设置或虚拟机。

• 借助迁移选项，可以在在触发迁移之前执行验证。 可以选择以下任一选项：

  • 验证 - 检查服务器和数据库就绪情况，以便迁移到目标。
  • 迁移 - 跳过验证并开始迁移。
  • 验证并迁移 - 在触发迁移之前执行验证。 仅当未发生验证失败时，才会触发迁移。

在运行迁移之前，选择“验证”或“验证并迁移”选项始终是执行预迁移验证时的良好做法。 若要详细了解迁移前验证，请参阅此文档。

• “迁移模式”允许选择迁移的模式。 “脱机”是默认选项。

选择“下一步: 连接到源”按钮。

选择运行时服务器

迁移运行时服务器是迁移服务中的一项专用功能，旨在充当迁移期间的中间服务器。 它是一个单独的 Azure Database for PostgreSQL 灵活服务器实例，该实例不是目标服务器，而是用于帮助从只能通过专用网络访问的源环境迁移数据库。

有关运行时服务器的详细信息，请访问迁移运行时服务器。

连接到源

“连接到源”选项卡提示你提供与“设置”选项卡中选择的源相关的详细信息，该源是数据库的源。

• 服务器名称 - 提供源 PostgreSQL 实例的主机名或 IP 地址
• 端口 - 源服务器的端口号
• 服务器管理员登录名 - 源 PostgreSQL 服务器的用户名
• 密码 - 源 PostgreSQL 服务器的密码
• SSL 模式 - 支持的值是首选值，也是必需值。 当源 PostgreSQL 服务器上的 SSL 为“关”时，请使用 SSLMODE=prefer。 如果源服务器上的 SSL 为“开”，请使用 SSLMODE=require。 SSL 值可以在 Postgresql.conf 文件中确定。
• 测试连接 - 执行目标与源之间的连接测试。 连接成功后，用户可以继续执行下一步操作。 否则，我们需要确定目标与源之间的网络问题，并验证源的用户名/密码。 建立测试连接需要几分钟时间。

测试连接成功后，选择“下一步: 选择迁移目标”

选择迁移目标

“选择迁移目标”选项卡显示灵活服务器目标的元数据，例如订阅名称、资源组、服务器名称、位置和 PostgreSQL 版本。

• 管理员用户名 - 目标 PostgreSQL 服务器的管理员用户名
• 密码 - 目标 PostgreSQL 服务器的密码
• 测试连接 - 执行目标与源之间的连接测试。 连接成功后，用户可以继续执行下一步操作。 否则，我们需要确定目标与源之间的网络问题，并验证目标的用户名/密码。 测试连接需要几分钟时间才能在目标与源之间建立连接。

测试连接成功后，选择“下一步: 选择要迁移的数据库”

选择要迁移的数据库

在此选项卡下，用户数据库列表位于设置选项卡中选择的源服务器内。可以在一次迁移尝试中选择和迁移最多 8 个数据库。 如果用户数据库超过 8 个，则会在源服务器和目标服务器之间针对下一组数据库重复迁移过程。

选择数据库后，选择“下一步: 摘要”

总结

“摘要”选项卡汇总了用于创建验证或迁移的所有源和目标详细信息。 查看详细信息，然后选择开始按钮。

监视迁移

选择“开始”按钮后，会在几秒钟内显示一条通知，指出验证或迁移创建已成功。 然后，你将自动重定向到灵活服务器的“迁移”页面，其中显示了最近创建的验证或迁移的新条目。

显示迁移的网格将包含以下列：“名称”、“状态”、“迁移模式”、“迁移类型”、“源服务器”、“源服务器类型”、“数据库”、“持续时间”和“开始时间”。 条目按开始时间降序显示，最新条目位于顶部。 可以使用“刷新”按钮刷新验证或迁移的状态。 在网格中选择迁移名称以查看关联的详细信息。

创建验证或迁移后，它会进入“InProgress”状态和“PerformingPreRequisiteSteps”子状态。 该工作流需要 2-3 分钟来设置迁移基础结构和网络连接。

迁移详细信息

在“设置”选项卡中，我们已选择迁移选项“迁移并验证”。 在这种情况下，将先执行验证，然后再执行迁移。 完成“PerformingPreRequisiteSteps”子状态后，工作流将进入“正在进行验证”子状态。

• 如果验证出现错误，迁移将进入“失败”状态。
• 如果验证完成且未出现任何错误，迁移会开始，并且工作流将进入“正在迁移数据”子状态。

可以在实例和数据库级别查看验证和迁移的结果。

部分可能的迁移状态：

迁移状态

迁移子状态

验证子状态

直接转换

如果同时存在“迁移”和“验证并迁移”，则需要执行另一个步骤才能完成联机迁移 - 用户必须执行直接转换操作。 完成基础数据的复制/克隆后，迁移将进入 WaitingForUserAction 状态和“WaitingForCutoverTrigger”子状态。 在这种状态下，用户可以通过选择迁移从门户触发直接转换。

在启动直接转换之前，请务必确保：

• 已停止写入源 - Latency 值为 0 或接近 0。 可以从迁移详细信息屏幕中获取 Latency 信息，如下所示：

  

• latency 值减小为 0 或接近 0

• latency 值表示目标上次与源同步的时间。 此时，可以停止写入源并启动直接转换。 如果源中存在大量流量，建议先停止写入，以便 Latency 可以接近 0，然后启动直接转换。 直接转换操作会将源中所有挂起的更改应用到目标，并完成迁移。 如果触发“直接转换”，则即使 Latency, 非零，复制也会在该时间点之前停止。 在目标上应用直接转换点之前源中的所有数据。 假设直接转换点处的延迟为 15 分钟，则会向目标应用过去 15 分钟内的所有更改数据。 所需时间取决于过去 15 分钟内发生的更改积压工作。 因此，建议在触发直接转换之前，延迟应达到零或接近零。

  

• 进入 Migrating Data 子状态或直接转换（联机迁移中）成功完成后，迁移将进入 Succeeded 状态。 如果 Migrating Data 子状态出现问题，迁移将进入 Failed 状态。

  

本文介绍了如何使用 Azure CLI 将 PostgreSQL 数据库从 Amazon Aurora 迁移到 Azure Database for PostgreSQL。 Azure CLI 提供强大而灵活的命令行接口用于执行各种任务，包括数据库迁移。 可以按照本文中所述的步骤将数据库无缝转移到 Azure，并利用其强大功能和可伸缩性。

若要详细了解如何将 Azure CLI 用于迁移服务，请访问如何为迁移服务安装 Azure CLI。

安装 CLI 后，打开命令提示符并使用以下命令登录到 Azure 帐户。

az login

配置迁移任务

若要开始迁移，需要创建一个包含迁移详细信息的 JSON 文件。 该 JSON 文件包含以下信息：

• 在各 JSON 行中编辑以下占位符 << >>，并将它们以 <<filename>>.json 的形式存储在调用 CLI 的本地计算机中。 在本教程中，我们已将文件保存在 C:\migration-CLI\migration_body.json 下

{
	"properties": {
		"SourceDBServerResourceId": "<<source hostname or IP address>>:<<port>>@<<username>>",
		"SecretParameters": {
			"AdminCredentials": {
				"SourceServerPassword": "<<Source Password>>",
				"TargetServerPassword": "<<Target Password>>"
			},
			"targetServerUserName": "<<Target username>>"
		},
		"DBsToMigrate": "<<comma separated list of databases in a array like - ["ticketdb","timedb","inventorydb"]>>",
		"OverwriteDBsInTarget": "true",
		"sourceType": "AWS_AURORA",
		"sslMode": "Require"
	}
}

• 运行以下命令以检查是否有迁移正在运行。 迁移名称在 Azure Database for PostgreSQL 灵活服务器目标内的所有迁移中是唯一的。

  az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

• 在上述步骤中，没有执行迁移，因此我们首先运行以下命令来启动新迁移

  az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

• 运行以下命令以启动上一步中的迁移状态。 你可以通过提供迁移名称来检查迁移的状态

  az postgres flexible-server migration show --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

• 迁移进度的状态会显示在 Azure CLI 中。

• 还可以在 Azure 门户中查看 Azure Database for PostgreSQL 灵活服务器的状态。

• 可以使用 cancel 命令取消任何正在进行的迁移尝试。 此命令会停止特定的迁移尝试并回滚目标服务器上的所有更改。 下面是用于删除迁移的 CLI 命令：

  az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

直接转换

• 在联机迁移中完成基础数据迁移后，迁移任务将进入 WaitingForCutoverTrigger 子状态。 在此状态下，用户可以使用以下命令通过 CLI 触发直接转换。 还可以通过选择迁移网格中的迁移名称从门户触发直接转换。

• 还可以从 Azure 门户启动直接转换。

  az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --cutover