为持续迁移配置源 PostgreSQL 数据库

本页面介绍了如何为标准同构 PostgreSQL 迁移配置源数据库实例。如果您想使用快速启动迁移,请按照 使用快速启动迁移指南进行操作。快速启动迁移提供简化的迁移流程,该流程使用 pgnative 复制和基于 Private Service Connect 接口的专用连接。如需了解详情,请参阅 Database Migration Service 主文档中的 快速启动迁移简介。

此页面包含每个受支持来源的相关部分:

配置自行管理的 PostgreSQL 来源

如需为迁移过程配置自行管理的 PostgreSQL 源实例(本地或托管在 Compute Engine 虚拟机上),请执行以下操作:

  1. 对于自行管理的 PostgreSQL 来源,Database Migration Service 会迁移来源实例下的所有数据库,模板数据库 template0 和 template1 除外。
  2. 确保源实例包含默认的 postgres 数据库。 如果此数据库不存在,请在配置迁移之前创建它。
  3. 在 pg_hba.conf 文件中配置网络客户端身份验证。 添加条目,以允许来自目标 Cloud SQL 出站 IP 地址、VPC CIDR 范围或反向 SSH 堡垒主机的复制连接和数据库访问:
    # Allow replication connections
    host  replication  MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
    # Allow database access
    host  all          MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5

    重新加载 PostgreSQL 配置以应用 pg_hba.conf 规则:

    SELECT pg_reload_conf();
  4. 验证源数据库上安装的 PostgreSQL 扩展程序。 Database Migration Service 不会迁移 Cloud SQL 不支持的扩展程序。验证源数据库对象和应用查询是否未引用不受支持的扩展程序。 请先从源数据库中移除不受支持的扩展程序和引用,然后再继续。

    Database Migration Service 不会自动迁移 pg_cron 扩展程序,但 Cloud SQL for PostgreSQL 目标数据库支持该扩展程序。 如果您在源数据库中使用 pg_cron,请在提升迁移后在目标实例上重新安装并配置它。

  5. 在源实例中创建专用的迁移用户账号,并向其授予必要的权限:
    1. 使用管理员账号连接到源实例,创建用户并分配复制角色:
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
      ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
    2. 向迁移用户账号授予默认 postgres 数据库以及您要迁移的每个数据库所需的权限。在每个数据库上针对每个架构(信息架构和以 pg_ 开头的架构除外)运行以下命令:
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
      GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. 在要迁移的每个数据库(不包括 template0 和 template1)上安装 pglogical 扩展程序:
    • 对于 PostgreSQL 9.4 版:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;
      CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • 对于 PostgreSQL 9.5 及更高版本:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;
  7. 验证您的表是否具有主键。对于持续迁移,PostgreSQL 逻辑复制要求表具有主键,以便在变更数据捕获 (CDC) 阶段复制 UPDATE 和 DELETE 操作:
    • 具有主键的表会自动复制所有 INSERT、UPDATE 和 DELETE 操作。
    • 对于没有主键的表,Database Migration Service 仅支持在 CDC 阶段迁移初始快照和后续 INSERT 语句。您必须手动迁移 UPDATE 和 DELETE 语句。

      我们建议您在开始迁移之前,先向没有主键的表添加主键。 如需了解如何生成查询以列出 PostgreSQL 数据库中没有主键的表,或如何手动迁移 UPDATE 和 DELETE 操作,请参阅 调试和其他工具。

      或者,您也可以尝试使用快速启动迁移流程:一种简化的迁移场景,您可以在其中使用 REPLICA IDENTITY 迁移没有主键的表。如需了解详情,请参阅 使用快速启动迁移功能指南。

  8. 运行 PostgreSQL 9.5 及更早版本的来源:对于运行 9.6 之前 PostgreSQL 版本的来源实例,复制延迟指标不可用。如果您想使用此指标跟踪迁移进度,请参阅 启用复制延迟。
  9. 在 PostgreSQL 服务器上安装 pglogical 软件包并配置 WAL 和复制参数:
    1. 在数据库服务器主机操作系统上安装 pglogical 软件包。 如需了解适用于您的发行版的软件包和安装说明,请参阅 pglogical GitHub 代码库。
    2. 使用管理员账号连接到 PostgreSQL 实例,并设置以下参数:
      1. 将 shared_preload_libraries 设置为包含 'pglogical':
        ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
      2. 将 wal_level 设置为 'logical':
        ALTER SYSTEM SET wal_level = 'logical';

        请参阅 PostgreSQL 文档中的 wal_level。

      3. 将 wal_sender_timeout 设置为 0:
        ALTER SYSTEM SET wal_sender_timeout = 0;

        0 值会停用用于终止非活跃复制连接的超时机制。 请参阅 wal_sender_timeout。

      4. 将 max_replication_slots 至少设置为要迁移的数据库数量乘以迁移作业数量,再加上表同步的预留数量:

        例如,如果源实例上有 5 个数据库,并且您为该源创建了 2 个迁移作业,那么复制槽的数量必须至少为 5 * 2 = 10,再加上其他任务已在源上使用的复制槽数量。如果您计划使用调整后的数据转储并行设置,请务必增加复制槽的数量,并在创建迁移作业时 运行迁移作业测试来验证您的配置。

        ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;

        此参数的默认值为 10。请参阅 max_replication_slots。

      5. 将 max_wal_senders 设置为至少是 max_replication_slots 的值加上实例中已使用的发送方数量:

        例如,如果 max_replication_slots 参数设置为 10,并且您已经使用 2 个发送器,则同时运行的 WAL 发送器进程的数量将为 10 + 2 = 12。 如果您计划使用调整后的数据转储并行设置,请务必增加发送器数量,并在创建迁移作业时 运行迁移作业测试来验证配置。

        ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

        此参数的默认值为 10。请参阅 max_wal_senders。

      6. 将 max_worker_processes 设置为至少是待迁移数据库的数量加上实例上现有的工作器进程数量。如果您计划使用调整后的数据转储并行设置,请为每个连接额外考虑两个工作器进程(最多 20 个工作器):
        ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;

        此参数的默认值为 8。请参阅 max_worker_processes。

  10. 重启 PostgreSQL 服务器,使配置更改生效。

配置 Amazon RDS for PostgreSQL 来源

如需为迁移过程配置 Amazon RDS for PostgreSQL 源实例,请执行以下操作:

  1. 对于 Amazon RDS for PostgreSQL 来源,Database Migration Service 会迁移来源实例下的所有数据库,但模板数据库 template0、template1 和 AWS 内部数据库 rdsadmin 除外。
  2. 确保源实例包含默认的 postgres 数据库。 如果此数据库不存在,请在配置迁移之前创建它。
  3. 配置 Amazon RDS VPC 安全群组入站规则。 允许来自目标 Cloud SQL 出站 IP 地址、VPC CIDR 范围或反向 SSH 堡垒机虚拟机在端口 5432 上的传入 TCP 连接。
  4. 验证源数据库上安装的 PostgreSQL 扩展程序。 Database Migration Service 不会迁移 Cloud SQL 不支持的扩展程序。验证源数据库对象和应用查询是否未引用不受支持的扩展程序。 请先从源数据库中移除不受支持的扩展程序和引用,然后再继续。

    Database Migration Service 不会自动迁移 pg_cron 扩展程序,但 Cloud SQL for PostgreSQL 目标数据库支持该扩展程序。 如果您在源数据库中使用 pg_cron,请在提升迁移后在目标实例上重新安装并配置它。

  5. 在源实例中创建专用的迁移用户账号,并向其授予必要的权限:
    1. 使用管理员账号连接到源实例,创建用户,并授予 AWS 管理的 rds_replication 角色:
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
      GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
    2. 向迁移用户账号授予默认 postgres 数据库以及您要迁移的每个数据库所需的权限。在每个数据库上针对每个架构(信息架构和以 pg_ 开头的架构除外)运行以下命令:
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
      GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. 在要迁移的每个数据库(不包括 template0、template1 和 rdsadmin)上安装 pglogical 扩展程序:
    • 对于 PostgreSQL 9.4 版:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;
      CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • 对于 PostgreSQL 9.5 及更高版本:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;

    如需详细了解相关要求,请参阅 AWS 文档中的 将 PostgreSQL 扩展程序与 Amazon RDS for PostgreSQL 搭配使用。

  7. 验证您的表是否具有主键。对于持续迁移,PostgreSQL 逻辑复制要求表具有主键,以便在变更数据捕获 (CDC) 阶段复制 UPDATE 和 DELETE 操作:
    • 具有主键的表会自动复制所有 INSERT、UPDATE 和 DELETE 操作。
    • 对于没有主键的表,Database Migration Service 仅支持在 CDC 阶段迁移初始快照和后续 INSERT 语句。您必须手动迁移 UPDATE 和 DELETE 语句。

      我们建议您在开始迁移之前,先向没有主键的表添加主键。 如需了解如何生成查询以列出 PostgreSQL 数据库中没有主键的表,或如何手动迁移 UPDATE 和 DELETE 操作,请参阅 调试和其他工具。

      或者,您也可以尝试使用快速启动迁移流程:一种简化的迁移场景,您可以在其中使用 REPLICA IDENTITY 迁移没有主键的表。如需了解详情,请参阅 使用快速启动迁移功能指南。

  8. 运行 PostgreSQL 9.5 及更早版本的来源:对于运行 9.6 之前 PostgreSQL 版本的来源实例,复制延迟指标不可用。如果您想使用此指标跟踪迁移进度,请参阅 启用复制延迟。
  9. 配置自定义数据库参数组并将其附加到实例:
    1. 创建自定义参数组(请参阅 AWS 文档中的 使用数据库参数组),并配置以下参数:
      1. 将 shared_preload_libraries 设置为包含 pglogical。
      2. 将 rds.logical_replication 设置为 1。此参数会在 Amazon RDS 中启用逻辑 WAL 日志记录。 请参阅 Amazon RDS for PostgreSQL 的逻辑复制。
      3. 将 wal_sender_timeout 设置为 0。值 0 可停用用于终止非活跃复制连接的超时机制。
      4. 将 max_replication_slots 至少设置为要迁移的数据库数量乘以迁移作业数量,再加上表同步的预留数量:

        例如,如果源实例上有 5 个数据库,并且您为该源创建了 2 个迁移作业,那么复制槽的数量必须至少为 5 * 2 = 10,再加上其他任务已在源上使用的复制槽数量。如果您计划使用调整后的数据转储并行设置,请务必增加复制槽的数量,并在创建迁移作业时 运行迁移作业测试来验证您的配置。

        此参数的默认值为 10。

      5. 将 max_wal_senders 设置为至少是 max_replication_slots 的值加上实例中已使用的发送方数量:

        例如,如果 max_replication_slots 参数设置为 10,并且您已经使用 2 个发送器,则同时运行的 WAL 发送器进程的数量将为 10 + 2 = 12。 如果您计划使用调整后的数据转储并行设置,请务必增加发送器数量,并在创建迁移作业时 运行迁移作业测试来验证配置。

        此参数的默认值为 10。

      6. 将 max_worker_processes 设置为至少是待迁移数据库的数量加上实例上现有工作器进程的数量。如果您计划使用调整后的数据转储并行设置,请为每个连接额外考虑两个工作器进程(最多 20 个工作器):

        此参数的默认值为 8。

    2. 将参数组附加到 RDS 数据库实例。如果您要创建新实例,可以在其他配置下找到此选项。否则,请修改实例以附加参数组。
  10. 重启 Amazon RDS 实例,使参数组更改生效。

配置 Amazon Aurora for PostgreSQL 来源

如需为迁移过程配置 Amazon Aurora PostgreSQL 源集群,请执行以下操作:

  1. 对于 Amazon Aurora for PostgreSQL 来源,Database Migration Service 会迁移源集群下的所有数据库,但模板数据库 template0、template1 和 AWS 内部数据库 rdsadmin 除外。
  2. 确保源集群包含默认的 postgres 数据库。 如果此数据库不存在,请在配置迁移之前创建它。
  3. 配置 Amazon Aurora 集群 VPC 安全群组入站规则。 允许来自目标 Cloud SQL 出站 IP 地址、VPC CIDR 范围或反向 SSH 堡垒机虚拟机在端口 5432 上的传入 TCP 连接。
  4. 验证源数据库上安装的 PostgreSQL 扩展程序。 Database Migration Service 不会迁移 Cloud SQL 不支持的扩展程序。验证源数据库对象和应用查询是否未引用不受支持的扩展程序。 请先从源数据库中移除不受支持的扩展程序和引用,然后再继续。

    Database Migration Service 不会自动迁移 pg_cron 扩展程序,但 Cloud SQL for PostgreSQL 目标数据库支持该扩展程序。 如果您在源数据库中使用 pg_cron,请在提升迁移后在目标实例上重新安装并配置它。

  5. 在源集群中创建专用的迁移用户账号,并向其授予必要的权限:
    1. 使用管理员账号连接到源集群,创建用户,并授予 AWS 管理的 rds_replication 角色:
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
      GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
    2. 向迁移用户账号授予默认 postgres 数据库以及您要迁移的每个数据库所需的权限。在每个数据库上针对每个架构(信息架构和以 pg_ 开头的架构除外)运行以下命令:
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
      GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. 在要迁移的每个数据库(不包括 template0、template1 和 rdsadmin)上安装 pglogical 扩展程序:
    CREATE EXTENSION IF NOT EXISTS pglogical;
  7. 验证您的表是否具有主键。对于持续迁移,PostgreSQL 逻辑复制要求表具有主键,以便在变更数据捕获 (CDC) 阶段复制 UPDATE 和 DELETE 操作:
    • 具有主键的表会自动复制所有 INSERT、UPDATE 和 DELETE 操作。
    • 对于没有主键的表,Database Migration Service 仅支持在 CDC 阶段迁移初始快照和后续 INSERT 语句。您必须手动迁移 UPDATE 和 DELETE 语句。

      我们建议您在开始迁移之前,先向没有主键的表添加主键。 如需了解如何生成查询以列出 PostgreSQL 数据库中没有主键的表,或如何手动迁移 UPDATE 和 DELETE 操作,请参阅 调试和其他工具。

      或者,您也可以尝试使用快速启动迁移流程:一种简化的迁移场景,您可以在其中使用 REPLICA IDENTITY 迁移没有主键的表。如需了解详情,请参阅 使用快速启动迁移功能指南。

  8. 配置自定义数据库集群参数组,并将其附加到您的集群:
    1. 创建自定义数据库集群参数组,并配置以下参数:
      1. 将 shared_preload_libraries 设置为包含 pglogical。
      2. 将 rds.logical_replication 设置为 1。此参数可启用逻辑 WAL 日志记录。
      3. 将 wal_sender_timeout 设置为 0。值 0 可停用用于终止非活跃复制连接的超时机制。
      4. 将 max_replication_slots 至少设置为要迁移的数据库数量乘以迁移作业数量,再加上表同步的预留数量:

        例如,如果源实例上有 5 个数据库,并且您为该源创建了 2 个迁移作业,那么复制槽的数量必须至少为 5 * 2 = 10,再加上其他任务已在源上使用的复制槽数量。如果您计划使用调整后的数据转储并行设置,请务必增加复制槽的数量,并在创建迁移作业时 运行迁移作业测试来验证您的配置。

        此参数的默认值为 10。

      5. 将 max_wal_senders 设置为至少是 max_replication_slots 的值加上实例中已使用的发送方数量:

        例如,如果 max_replication_slots 参数设置为 10,并且您已经使用 2 个发送器,则同时运行的 WAL 发送器进程的数量将为 10 + 2 = 12。 如果您计划使用调整后的数据转储并行设置,请务必增加发送器数量,并在创建迁移作业时 运行迁移作业测试来验证配置。

        此参数的默认值为 10。

      6. 将 max_worker_processes 设置为至少是待迁移数据库的数量加上实例上现有工作器进程的数量。如果您计划使用调整后的数据转储并行设置,请为每个连接额外考虑两个工作器进程(最多 20 个工作器):

        此参数的默认值为 8。

    2. 将数据库集群参数组附加到 Aurora 数据库集群。
  9. 重启 Amazon Aurora 数据库集群,使参数组更改生效。

配置 Microsoft Azure Database for PostgreSQL Flexible Server 来源

如需为迁移过程配置 Microsoft Azure Database for PostgreSQL Flexible Server 源实例,请执行以下操作:

  1. 对于 Microsoft Azure Database for PostgreSQL Flexible Server 源,Database Migration Service 会迁移源实例下的所有数据库,但不包括 Azure 系统和模板数据库:azure_maintenance、azure_sys、template0 和 template1。
  2. 确保源实例包含默认的 postgres 数据库。 如果此数据库不存在,请在配置迁移之前创建它。
  3. 配置 Azure 防火墙和 SSL/TLS 设置:
    1. 在 Azure 网络设置中,添加防火墙规则,以允许来自目标 Cloud SQL 出站 IP 地址、VPC CIDR 范围或反向 SSH 堡垒机虚拟机在端口 5432 上的入站 TCP 连接。
    2. 检查 require_secure_transport 服务器参数的值。 默认情况下,Azure 数据库要求对传入连接使用 SSL/TLS 加密。根据 require_secure_transport 设置,在创建来源连接配置文件时,选择以下加密设置之一:
      • 如果 require_secure_transport 设置为 on,请选择基本、TLS 或 mTLS。
      • 如果 require_secure_transport 设置为 off,请选择无。
  4. 验证源数据库上安装的 PostgreSQL 扩展程序。 Database Migration Service 不会迁移 Cloud SQL 不支持的扩展程序。验证源数据库对象和应用查询是否未引用不受支持的扩展程序。 请先从源数据库中移除不受支持的扩展程序和引用,然后再继续。

    Database Migration Service 不会自动迁移 pg_cron 扩展程序,但 Cloud SQL for PostgreSQL 目标数据库支持该扩展程序。 如果您在源数据库中使用 pg_cron,请在提升迁移后在目标实例上重新安装并配置它。

  5. 在源实例中创建专用的迁移用户账号,并向其授予必要的权限:
    1. 使用管理员账号连接到源实例,创建用户并分配复制角色:
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
      ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
    2. 向迁移用户账号授予默认 postgres 数据库以及您要迁移的每个数据库所需的权限。在每个数据库上针对每个架构(信息架构和以 pg_ 开头的架构除外)运行以下命令:
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
      GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. 在要迁移的每个数据库(不包括 azure_maintenance、azure_sys、template0 和 template1)上安装 pglogical 扩展程序:
    • 对于 PostgreSQL 9.4 版:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;
      CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • 对于 PostgreSQL 9.5 及更高版本:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;
  7. 验证您的表是否具有主键。对于持续迁移,PostgreSQL 逻辑复制要求表具有主键,以便在变更数据捕获 (CDC) 阶段复制 UPDATE 和 DELETE 操作:
    • 具有主键的表会自动复制所有 INSERT、UPDATE 和 DELETE 操作。
    • 对于没有主键的表,Database Migration Service 仅支持在 CDC 阶段迁移初始快照和后续 INSERT 语句。您必须手动迁移 UPDATE 和 DELETE 语句。

      我们建议您在开始迁移之前,向没有主键的表添加主键。 如需了解如何生成查询以列出 PostgreSQL 数据库中没有主键的表,或如何手动迁移 UPDATE 和 DELETE 操作,请参阅 调试和其他工具。

      或者,您也可以尝试使用快速启动迁移流程:一种简化的迁移场景,您可以在其中使用 REPLICA IDENTITY 迁移没有主键的表。如需了解详情,请参阅 使用快速启动迁移功能指南。

  8. 运行 PostgreSQL 9.5 及更早版本的来源:对于运行 9.6 之前 PostgreSQL 版本的来源实例,复制延迟指标不可用。如果您想使用此指标跟踪迁移进度,请参阅 启用复制延迟。
  9. 在 Azure 中配置以下服务器参数。如需了解详情,请参阅在 Azure Database for PostgreSQL 中配置服务器参数。
    1. 将 shared_preload_libraries 设置为包含 pglogical。
    2. 将 azure.extensions 设置为包含 pglogical。
    3. 将 wal_level 设置为 logical。
    4. 将 wal_sender_timeout 设置为 0。值 0 可停用用于终止非活跃复制连接的超时机制。
    5. 将 max_replication_slots 设置为至少等于要迁移的数据库数量乘以迁移作业数量,再加上表同步的预留数量:

      例如,如果源实例上有 5 个数据库,并且您为该源创建了 2 个迁移作业,那么复制槽的数量必须至少为 5 * 2 = 10,再加上其他任务已在源上使用的复制槽数量。 如果您计划使用调整后的数据转储并行设置,请务必增加复制槽的数量,并在创建迁移作业时 运行迁移作业测试来验证您的配置。

      此参数的默认值为 10。

    6. 将 max_wal_senders 设置为至少是 max_replication_slots 的值加上实例中已使用的发送方数量:

      例如,如果 max_replication_slots 参数设置为 10,并且您已经使用 2 个发送器,则同时运行的 WAL 发送器进程的数量将为 10 + 2 = 12。 如果您计划使用调整后的数据转储并行设置,请务必增加发送器数量,并在创建迁移作业时 运行迁移作业测试来验证配置。

      此参数的默认值为 10。

    7. 将 max_worker_processes 设置为至少是待迁移数据库的数量加上实例上现有的工作器进程数量。 如果您计划使用调整后的数据转储并行设置,请为每个连接额外考虑两个工作器进程(最多 20 个工作器):

      此参数的默认值为 8。

    如需了解更多参数详情,请参阅 Microsoft 文档中 Azure Database for PostgreSQL 中的所有服务器参数列表。

  10. 重启 Microsoft Azure Database for PostgreSQL Flexible Server 实例,使服务器参数更改生效。

配置 Cloud SQL for PostgreSQL 来源

如需为迁移过程配置 Cloud SQL for PostgreSQL 源实例,请执行以下操作:

  1. 对于 Cloud SQL for PostgreSQL 源,Database Migration Service 会迁移源实例下的所有数据库,模板数据库 template0 和 template1 除外。
  2. 确保源实例包含默认的 postgres 数据库。 如果此数据库不存在,请在配置迁移之前创建它。
  3. 如果您从配置了专用 IP 地址的 Cloud SQL 源实例迁移到使用非 RFC 1918 地址 IP 范围的 Cloud SQL 目标实例,请将非 RFC 1918 范围添加到源实例的已获授权的网络。如需了解详情,请参阅 配置已获授权的网络。
  4. 验证源数据库上安装的 PostgreSQL 扩展程序。 Database Migration Service 不会迁移 Cloud SQL 不支持的扩展程序。验证源数据库对象和应用查询是否未引用不受支持的扩展程序。请先从源数据库中移除不受支持的扩展程序和引用,然后再继续。

    Database Migration Service 不会自动迁移 pg_cron 扩展程序,但 Cloud SQL for PostgreSQL 目标数据库支持该扩展程序。如果您在源数据库中使用 pg_cron,请在提升迁移后在目标实例上重新安装并配置它。

  5. 在源实例中创建专用的迁移用户账号,并向其授予必要的权限:
    1. 按照 Cloud SQL 文档中 创建用户页面上的步骤操作。
    2. 向迁移用户账号授予默认 postgres 数据库以及您要迁移的每个数据库所需的权限。在每个数据库上针对每个架构(信息架构和以 pg_ 开头的架构除外)运行以下命令:
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
      GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
      GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. 在要迁移的每个数据库(不包括 template0 和 template1)上安装 pglogical 扩展程序:
    • 对于 PostgreSQL 9.4 版:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;
      CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • 对于 PostgreSQL 9.5 及更高版本:运行以下命令:
      CREATE EXTENSION IF NOT EXISTS pglogical;
  7. 验证您的表是否具有主键。对于持续迁移,PostgreSQL 逻辑复制要求表具有主键,以便在变更数据捕获 (CDC) 阶段复制 UPDATE 和 DELETE 操作:
    • 具有主键的表会自动复制所有 INSERT、UPDATE 和 DELETE 操作。
    • 对于没有主键的表,Database Migration Service 会在 CDC 阶段迁移初始快照和后续 INSERT 语句。您必须手动迁移 UPDATE 和 DELETE 语句。

      我们建议您在开始迁移之前,向没有主键的表添加主键。 如需了解如何生成查询以列出 PostgreSQL 数据库中没有主键的表,或如何手动迁移 UPDATE 和 DELETE 操作,请参阅 调试和其他工具。

      或者,您也可以尝试使用快速启动迁移流程:一种简化的迁移场景,您可以在其中使用 REPLICA IDENTITY 迁移没有主键的表。如需了解详情,请参阅 使用快速启动迁移功能指南。

  8. 运行 PostgreSQL 9.5 及更早版本的来源:对于运行 9.6 之前 PostgreSQL 版本的来源实例,复制延迟指标不可用。如果您想使用此指标跟踪迁移进度,请参阅 启用复制延迟。
  9. 在 Cloud SQL 源实例上配置以下数据库标志:
    1. 将 cloudsql.logical_decoding 设置为 on。
    2. 将 cloudsql.enable_pglogical 设置为 on。
    3. 将 wal_sender_timeout 设置为 0。值 0 可停用用于终止非活跃复制连接的超时机制。
    4. 将 max_replication_slots 至少设置为要迁移的数据库数量乘以迁移作业数量,再加上表同步的预留数量

      例如,如果源实例上有 5 个数据库,并且您为该源创建了 2 个迁移作业,那么复制槽的数量必须至少为 5 * 2 = 10,再加上源上已被其他任务使用的复制槽数量。 如果您计划使用调整后的数据转储并行设置,请务必增加复制槽的数量,并在创建迁移作业时 运行迁移作业测试来验证您的配置。

      此标志的默认值为 10。

    5. 将 max_wal_senders 设置为至少是 max_replication_slots 的值加上实例中已使用的发送方数量。

      例如,如果 max_replication_slots 标志设置为 10,并且您已经使用 2 个发送器,则同时运行的 WAL 发送器进程的数量将为 10 + 2 = 12。 如果您计划使用调整后的数据转储并行设置,请务必增加发送器数量,并在创建迁移作业时 运行迁移作业测试来验证配置。

      此标志的默认值为 10。

    6. 将 max_worker_processes 设置为至少是待迁移数据库的数量加上实例上现有的工作器进程数量。 如果您打算使用调整后的数据转储并行设置,请为每个连接额外考虑两个工作器进程(最多 20 个工作器)。

      此标志的默认值为 8。

    如需详细了解如何修改标志,请参阅 Cloud SQL 文档中的配置数据库标志。

  10. 重启源 Cloud SQL 实例,使数据库标志更改生效。

后续步骤