你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
教程：使用迁移服务预览版从 Google Cloud SQL for PostgreSQL 在线迁移到 Azure Database for PostgreSQL
本文介绍如何将 PostgreSQL 数据库从 Google Cloud SQL for PostgreSQL 在线迁移到 Azure Database for PostgreSQL。
Azure Database for PostgreSQL 中的迁移服务是集成到 Microsoft Azure 门户和 Azure CLI 中的完全托管服务。 它旨在简化迁移到 Azure Database for PostgreSQL 服务器的过程。
- 先决条件
- 执行迁移
- 监视迁移
- 直接转换
- 完成后检查迁移
先决条件
若要完成迁移，需满足以下先决条件：
在开始使用 Azure Database for PostgreSQL 迁移服务进行迁移之前，必须满足以下专为联机迁移方案规定的先决条件。
验证源版本
源 PostgreSQL 服务器版本必须为 9.5 或更高。
如果源 PostgreSQL 版本低于 9.5，请在开始迁移之前将其升级到 9.5 或更高版本。
注意
Azure Database for PostgreSQL 中的迁移服务支持使用源 Google Cloud SQL for PostgreSQL 的 IP 地址进行连接。 不支持 myproject:myregion:myinstance 格式。
安装 test_decoding - 源设置
- test_decoding 通过逻辑解码机制接收 WAL，并将其解码为所执行操作的文本表示形式。
- 在 Google Cloud SQL for PostgreSQL 中，test_decoding 插件已预先安装并随时可用于逻辑复制。 这样，你便可以轻松设置逻辑复制槽并流式传输 WAL 更改，从而简化变更数据捕获 (CDC) 或复制到外部系统等用例。
- 有关 test-decoding 插件的详细信息，请参阅 PostgreSQL 文档
配置目标设置
- 在迁移之前，必须创建 Azure Database for PostgreSQL 灵活服务器。
- 为 Azure Database for PostgreSQL 灵活服务器预配的 SKU 应与源匹配。
- 若要创建新的 Azure Database for PostgreSQL，请访问创建 Azure Database for PostgreSQL
启用 CDC 作为源
test_decoding逻辑解码插件从源捕获已更改的记录。- 若要确保迁移用户具有所需的复制权限，请执行以下 SQL 命令：
Alter user <<username>> with REPLICATION;
转到 Google Cloud 控制台中的 Google Cloud SQL PostgreSQL 实例，单击实例名称以打开其详细信息页，单击“编辑”按钮，然后在“标志”部分中修改以下标志：
- 设置标志
cloudsql.logical_decoding = on - 将标志
max_replication_slots设置为大于 1 的值；该值应大于选择进行迁移的数据库数量。 - 将标志
max_wal_senders设置为大于 1 的值。 该值至少应与max_replication_slots相同，加上实例上已使用的发送器数量。 - 标志
wal_sender_timeout将结束持续时间超过指定毫秒数的非活动复制连接。 将该值设置为 0（零）会禁用超时机制，这也是迁移的有效设置。
- 设置标志
在目标灵活服务器中，若要防止联机迁移耗尽存储来存储日志，请确保使用预配的托管磁盘有足够的表空间。 为此，请在迁移期间禁用服务器参数
azure.enable_temp_tablespaces_on_local_ssd，并在迁移后将其还原到原始状态。
配置网络设置
网络设置对于迁移服务正常运行至关重要。 确保源 PostgreSQL 服务器可与目标 Azure Database for PostgreSQL 服务器通信。 以下网络配置对于成功迁移至关重要。
有关网络设置的信息，请访问迁移服务的网络指南。
启用扩展
要确保使用 Azure Database for PostgreSQL 中的迁移服务成功进行迁移，可能需要验证源 PostgreSQL 实例的扩展。 扩展提供了应用程序可能需要的功能和特征。 在启动迁移过程之前，请确保验证源 PostgreSQL 实例上的扩展。
在 Azure Database for PostgreSQL 灵活服务器的目标实例中，启用在源 PostgreSQL 实例中标识的受支持的扩展。
有关详细信息，请参阅 Azure Database for PostgreSQL 中的扩展。
注意
只要更改 shared_preload_libraries 参数，就需要重启。
检查服务器参数
这些参数不会自动迁移到目标环境，必须手动进行配置。
通过访问 Microsoft Azure 门户中的“服务器参数”部分并相应地手动更新相关值，将源 PostgreSQL 数据库中的服务器参数值与 Azure Database for PostgreSQL 相匹配。
保存参数更改并重启 Azure Database for PostgreSQL 以应用新配置（如果需要）。
检查用户和角色
迁移到 Azure Database for PostgreSQL 时，必须单独解决用户和角色的迁移问题，因为它们需要手动干预：
手动迁移用户和角色：用户及其关联的角色必须以手动方式迁移到 Azure Database for PostgreSQL。 为了方便此过程，可以将
pg_dumpall实用工具与--globals-only标志一起使用，以导出角色和用户帐户等全局对象。 请执行以下命令，但要将<<username>>替换为实际的用户名，并将<<filename>>替换为所需的输出文件名：pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql对超级用户角色的限制：Azure Database for PostgreSQL 不支持超级用户角色。 因此，具有超级用户权限的用户必须在迁移之前移除这些权限。 请确保相应地调整权限和角色。
通过执行这些步骤，可以确保用户帐户和角色正确迁移到 Azure Database for PostgreSQL，而不会遇到与超级用户限制相关的问题。
在目标中禁用高可用性（可靠性）和只读副本
在目标环境中禁用高可用性（可靠性）和只读副本至关重要。 只有在迁移完成后才能启用这些功能。
遵循这些准则有助于避免因 HA 和只读副本而引入更多变量，确保迁移过程顺利进行。 迁移完成并且数据库稳定后，可以继续启用这些功能，以提高 Azure 中数据库环境的可用性和可伸缩性。
执行迁移
可以使用 Azure 门户或 Azure CLI 进行迁移。
Azure 门户提供简单直观的基于向导的体验，可引导你完成迁移。 遵循本教程中所述的步骤，可以将数据库无缝转移到 Azure Database for PostgreSQL 灵活服务器，并利用其强大的功能和可伸缩性。
若要使用 Azure 门户进行迁移，首先请配置迁移任务，连接到源和目标，然后执行迁移。
配置迁移任务
该迁移服务在 Microsoft Azure 门户中提供了一种基于向导的简单体验。 下面介绍如何开始：
打开 Web 浏览器并转到门户。 输入凭据登录。 默认视图是服务仪表板。
转到你的 Azure Database for PostgreSQL 灵活服务器目标。
在灵活服务器的“概述”选项卡的左侧菜单中，向下滚动到“迁移”并将其选中。
选择“创建”按钮，以从 Google Cloud SQL for PostgreSQL 迁移到 Azure Database for PostgreSQL 灵活服务器。 第一次使用迁移服务时，将会显示一个空网格，并提示你开始第一次迁移。
如果已创建到 Azure Database for PostgreSQL 目标的迁移，则网格将包含有关尝试的迁移的信息。
选择“创建”按钮。 然后，完成基于向导的一系列选项卡中的操作，以创建从 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 服务器的密码
- 自定义 FQDN/IP（可选）：自定义 FQDN/IP 字段是可选的，可在目标位于自定义 DNS 服务器后面或具有自定义 DNS 命名空间时使用，这导致只能通过特定的 FQDN 或 IP 地址对它进行访问。 例如，如果自定义 DNS 服务器包含 DNS 区域
postgres.database.azure.com或将此区域的查询转发至168.63.129.16，则可能包括flexibleserver.example.com、198.1.0.2或 PostgreSQL FQDN（如flexibleserver.postgres.database.azure.com）之类的条目，其中 FQDN 在 Azure 公共或专用 DNS 区域中已解析。 - 测试连接 - 执行目标与源之间的连接测试。 连接成功后，用户可以继续执行下一步操作。 否则，我们需要确定目标与源之间的网络问题，并验证目标的用户名/密码。 测试连接需要几分钟时间才能在目标与源之间建立连接。
测试连接成功后，选择“下一步: 选择要迁移的数据库”
选择要迁移的数据库
在此选项卡下，用户数据库列表位于设置选项卡中选择的源服务器内。可以在一次迁移尝试中选择和迁移最多 8 个数据库。 如果用户数据库超过 8 个，则会在源服务器和目标服务器之间针对下一组数据库重复迁移过程。
选择数据库后，选择“下一步: 摘要”
总结
“摘要”选项卡汇总了用于创建验证或迁移的所有源和目标详细信息。 查看详细信息，然后选择开始按钮。
监视迁移
选择“开始”按钮后，会在几秒钟内显示一条通知，指出验证或迁移创建已成功。 然后，你将自动重定向到灵活服务器的“迁移”页面，其中显示了最近创建的验证或迁移的新条目。
显示迁移的网格将包含以下列：“名称”、“状态”、“迁移模式”、“迁移类型”、“源服务器”、“源服务器类型”、“数据库”、“持续时间”和“开始时间”。 条目按开始时间降序显示，最新条目位于顶部。 可以使用“刷新”按钮刷新验证或迁移的状态。 在网格中选择迁移名称以查看关联的详细信息。
创建验证或迁移后，它会进入“InProgress”状态和“PerformingPreRequisiteSteps”子状态。 该工作流需要 2-3 分钟来设置迁移基础结构和网络连接。
迁移详细信息
在“设置”选项卡中，我们已选择迁移选项“迁移并验证”。 在这种情况下，将先执行验证，然后再执行迁移。 完成“PerformingPreRequisiteSteps”子状态后，工作流将进入“正在进行验证”子状态。
- 如果验证出现错误，迁移将进入“失败”状态。
- 如果验证完成且未出现任何错误，迁移会开始，并且工作流将进入“正在迁移数据”子状态。
可以在实例和数据库级别查看验证和迁移的结果。
部分可能的迁移状态：
迁移状态
| 状态 | 说明 |
|---|---|
| InProgress | 正在设置迁移基础结构，或者正在进行实际数据迁移。 |
| 已取消 | 迁移已被取消或删除。 |
| 已失败 | 迁移失败。 |
| 验证失败 | 验证失败。 |
| 成功 | 迁移成功并已完成。 |
| WaitingForUserAction | 仅适用于联机迁移。 等待用户操作以执行直接转换。 |
迁移子状态
| 子状态 | 说明 |
|---|---|
| PerformingPreRequisiteSteps | 正在设置基础结构以进行数据迁移。 |
| 验证正在进行 | 正在进行验证。 |
| MigratingData | 数据迁移正在进行中。 |
| CompletingMigration | 迁移处于完成的最后阶段。 |
| 已完成 | 迁移已完成。 |
| 已失败 | 迁移失败。 |
验证子状态
| 子状态 | 说明 |
|---|---|
| 已失败 | 验证失败。 |
| 成功 | 验证成功。 |
| 警告 | 验证处于警告状态。 |
直接转换
如果同时存在“迁移”和“验证并迁移”，则需要执行另一个步骤才能完成联机迁移 - 用户必须执行直接转换操作。 完成基本数据的复制/克隆后，迁移会进入 WaitingForUserAction 状态和 WaitingForCutoverTrigger 子状态。 在这种状态下，用户可以通过选择迁移从门户触发直接转换。
在启动直接转换之前，请务必确保：
已停止写入源 -
Latency值为 0 或接近 0。 可以从迁移详细信息屏幕中获取Latency信息，如下所示：
latency值减小为 0 或接近 0latency值表示目标上次与源同步的时间。 此时，可以停止写入源并启动直接转换。 如果源中存在大量流量，建议先停止写入，以便Latency可以接近 0，然后启动直接转换。 直接转换操作会将源中所有挂起的更改应用到目标，并完成迁移。 如果触发“直接转换”，则即使Latency,非零，复制也会在该时间点之前停止。 在目标上应用直接转换点之前源中的所有数据。 假设直接转换点处的延迟为 15 分钟，则会向目标应用过去 15 分钟内的所有更改数据。 所需时间取决于过去 15 分钟内发生的更改积压工作。 因此，建议在触发直接转换之前，延迟应达到零或接近零。
进入
Migrating Data子状态或直接转换（联机迁移中）成功完成后，迁移将进入Succeeded状态。 如果Migrating Data子状态出现问题，迁移将进入Failed状态。
完成后检查迁移
完成数据库后，需要人工在源和目标之间验证数据，并确认目标数据库中的所有对象都已成功创建。
迁移后，可以执行以下任务：
- 验证灵活服务器上的数据，并确保它是源实例的确切副本。
- 验证后，根据需要在灵活服务器上启用高可用性选项。
- 根据应用程序的需求更改灵活服务器的 SKU。 需要重启数据库服务器才能使此更改生效。
- 如果更改了源实例中任何服务器参数的默认值，请将这些服务器参数值复制到灵活服务器中。
- 将标记、警报和防火墙规则（如果适用）等其他服务器设置从源实例复制到灵活服务器。
- 更改应用程序以将连接字符串指向灵活服务器。
- 密切监视数据库性能，以查看是否需要进行性能优化。