配置来源

MySQL   |  PostgreSQL   |  PostgreSQL 到 AlloyDB

概览

Database Migration Service 支持从源数据库到 Cloud SQL 目标数据库的持续迁移。

PostgreSQL 支持的源数据库包括：

• Amazon RDS 9.6.10+、10.5+、11.1+、12、13、14、15、16、17、18。
• Amazon Aurora 10.11+、11.6+、12.4+、13.3+、14.6+、15.2+、16、17、18。
• 自行管理的 PostgreSQL（在本地或由您完全控制的任何云虚拟机上）9.4、9.5、9.6、10、11、12、13、14、15、16、17、18。
• Cloud SQL for PostgreSQL 9.6、10、11、12、13、14、15、16、17、18。
• Microsoft Azure Database for PostgreSQL Flexible Server：11+

配置来源需要同时配置源实例和底层源数据库。

配置源实例

如需配置源实例，请按照下列步骤操作：

1. 对于 Cloud SQL 源：如果您要从使用专用 IP 连接的 Cloud SQL 实例迁移到使用 非 RFC 1918 地址 IP 范围的 Cloud SQL 实例，请将非 RFC 1918 范围添加到源 Cloud SQL 实例的网络配置中。 请参阅 配置已获授权的网络 在 Cloud SQL 文档中。
2. 源实例必须包含 postgres 数据库。如果您没有此数据库，请创建一个。

3. 在源实例上安装 pglogical 软件包，并确保其包含在 shared_preload_libraries 变量中。请参阅 在源pglogical实例上安装 软件包以用于您的环境。

4. 验证源实例中的扩展程序。Database Migration Service 不会 迁移 Cloud SQL 不支持的扩展程序。 这些扩展程序的存在不会阻止迁移，但为了确保迁移过程顺利进行，请验证您的对象或应用是否引用了任何不受支持的扩展程序。我们建议您在继续操作之前，从源数据库中移除这些扩展程序和引用。

5. 对于使用 pg_cron 扩展程序的来源：Database Migration Service 不会迁移 pg_cron 扩展程序（或与该扩展程序关联的任何 cron 设置），但 Cloud SQL for PostgreSQL 目标数据库支持该扩展程序。如果您在源数据库中使用 pg_cron 扩展程序，则可以在迁移完成后在目标实例上重新安装该扩展程序。

配置源数据库

Database Migration Service 会迁移源实例下除了以下数据库之外的所有数据库 ：

• 对于本地 PostgreSQL 源：模板数据库 template0 和 template1
• 对于 Amazon RDS 源：template0、template1 和 rdsadmin
• 对于 Cloud SQL 源：模板数据库 template0 和 template1
• 对于 Microsoft Azure 源：azure_maintenance、azure_sys、template0、template1

针对上文未提到的源实例中的每个数据库 执行以下操作：

1. 仅对于 PostgreSQL 9.4 版来源，请在源实例中的每个数据库上安装以下 pglogical 扩展程序：

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

2. 对于所有其他版本，请在源实例中的每个数据库上仅安装 pglogical 扩展程序：CREATE EXTENSION IF NOT EXISTS pglogical。

3. 对于没有主键的表，Database Migration Service 支持在 CDC 阶段迁移初始快照和 INSERT 语句。您应手动迁移 UPDATE 和 DELETE 语句。

   如需了解如何生成查询以列出 PostgreSQL 数据库中没有主键的表，请参阅调试和其他工具。对于您发现的每个没有主键的数据库表，若该表不属于未迁移的数据库，您应 更改该表，使其具有主键或按照此过程操作。对于没有主键的表，只会迁移初始快照和 INSERT 语句。

4. 您用于连接到源实例的 USER（其将配置为连接配置文件页面中的用户）必须对每个已迁移数据库和默认的 postgres 数据库都具有特定权限。您可以创建新用户，也可以重复使用现有用户。如需设置这些权限，请连接到实例并运行以下命令：

   1. GRANT USAGE on SCHEMA SCHEMA to USER 针对要迁移的每个数据库中的所有架构（信息架构以及以“pg_”开头的架构除外）。
   2. 针对要迁移的每个数据库运行 GRANT USAGE on SCHEMA pglogical to PUBLIC;。
   3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER 针对所有数据库运行，以便从源数据库获取复制信息。
   4. GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER 针对要迁移的每个数据库中的所有架构（信息架构以及以“pg_”开头的架构除外）。
   5. GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER 针对要迁移的每个数据库中的所有架构（信息架构以及以“pg_”开头的架构除外）。
   6. 如果您的源数据库是 Amazon RDS，那么运行以下命令：
      1. GRANT rds_replication to USER
   7. 如果您的源数据库不是 Amazon RDS，那么运行以下命令：
      1. ALTER USER USER with REPLICATION 角色

在源实例上安装 pglogical 软件包

本部分介绍了如何根据您的源实例配置 pglogical 软件包和适用的参数。

**注意**： 您可以在创建迁移作业时 运行迁移作业测试，以获取这些参数的正确值。 在此测试期间，Database Migration Service 可以验证您的设置并建议正确的值。

本地或自行管理的 PostgreSQL

1. 在服务器上安装 pglogical 软件包。
2. 连接到实例并根据需要设置以下参数：

   • shared_preload_libraries 必须包含 pglogical。

     如需设置此参数，请运行 ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]'; 命令。

     如需获取实例的现有库，请运行 show shared_preload_libraries 命令。

   • 将 wal_level 设置为 logical。

     如需设置此参数，请运行 ALTER SYSTEM SET wal_level = 'logical'; 命令。

   • 将 wal_sender_timeout 设置为 0。

     如需设置此参数，请运行 ALTER SYSTEM SET wal_sender_timeout = 0; 命令，其中 0 可停用用于终止非活跃复制连接的超时机制。

   • max_replication_slots 定义了源实例可以支持的 复制槽数量上限。必须至少将其设置为预期连接的 订阅数，并预留一部分进行表 同步。

     Database Migration Service 要求为每个迁移的数据库（即源实例下的所有数据库）提供一个槽。

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

     如需设置此参数，请运行 ALTER SYSTEM SET max_replication_slots = #; 命令，其中 # 表示复制槽数量上限。

   • max_wal_senders 应设置为至少与 max_replication_slots 加上已在实例上使用的发送器数量相同。

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

     如需设置此参数，请运行 ALTER SYSTEM SET max_wal_senders = #; 命令，其中 # 表示同时运行的 WAL 发送器进程的数量。

   • max_worker_processes 应设置为至少与 Database Migration Service 将要迁移的数据库数量（即源实例下的所有数据库）加上已在实例上使用的 max_worker_processes 数量相同。

     如果您计划使用调整后的数据转储并行设置， 请务必增加工作器进程的数量，并 通过 运行迁移作业测试来验证您的配置， 创建迁移作业时。

     如需设置此参数，请运行 ALTER SYSTEM SET max_worker_processes = #; 命令，其中 # 表示将要迁移的数据库数量。

   您在此步骤中设置的参数适用于正在运行的 PostgreSQL 数据库服务器。您还可以通过将以下代码行添加到 postgresql.conf 文件来使这些更改保持不变：

   • shared_preload_libraries = 'pglogical';
   • wal_level = 'logical';
   • wal_sender_timeout = 0;
   • max_replication_slots = #;
   • max_wal_senders = #;
   • max_worker_processes = #;
3. 如需应用配置更改，请重启源实例 。

Microsoft Azure Database for PostgreSQL

如需配置 Microsoft Azure Database for PostgreSQL 源，请按照下列步骤操作：

1. 在服务器上安装 pglogical 软件包。

2. 仅对于 PostgreSQL 9.4 版来源，请在源实例中的每个数据库上安装以下 pglogical 扩展程序：

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

3. 对于所有其他版本，请在源实例中的每个数据库上安装 pglogical 扩展程序：CREATE EXTENSION IF NOT EXISTS pglogical。

4. 使用 Microsoft Azure 门户在源上配置所需的服务器参数。如需了解详情，请参阅 Microsoft 文档中的 在 Azure Database for PostgreSQL 中配置服务器参数 和 Azure Database for PostgreSQL 中的服务器参数。

   配置以下参数：

   • 将 shared_preload_libraries 设置为包含 pglogical 。
   • 将 azure.extensions 设置为包含 pglogical 。
   • 将 wal_level 设置为 logical 。

   • 将 max_replication_slots 设置为至少是预期连接的订阅数，并预留一部分进行表同步。

     max_replication_slots 参数定义了源实例可以支持的复制槽数量上限。

     Database Migration Service 要求为每个迁移的数据库（即源实例下的所有数据库）提供一个槽。

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

   • 将 max_wal_senders 设置为至少与 max_replication_slots 加上已在实例上使用的发送器数量相同。

     例如，如果 max_replication_slots 参数设置为 10，并且您已经使用 2 个发送器，则同时运行的 WAL 发送器进程的数量将为 10 + 2 = 12。

     如果您计划使用调整后的数据转储并行设置， 请务必增加发送器的数量，并 通过 运行迁移作业测试来验证您的配置， 当您创建迁移作业时。

   • 将 max_worker_processes 设置为至少与 Database Migration Service 将要迁移的数据库数量（即源实例下的所有数据库）加上已在实例上使用的 max_worker_processes 数量相同。

     如果您计划使用调整后的数据转储并行设置， 请务必增加工作器进程的数量，并 通过 运行迁移作业测试来验证您的配置， 创建迁移作业时。

5. 检查 require_secure_transport 设置的值。

   默认情况下，Microsoft Azure 数据库要求所有传入 连接都使用 SSL/TLS 加密。根据 require_secure_transport 的值，在 创建源连接配置文件时使用以下加密设置之一：

   • 如果 require_secure_transport 设置为 on，请选择 基本 、TLS 或 mTLS 。
   • 如果 require_secure_transport 设置为 off，请选择无 。
6. 如需应用配置更改，请重启源实例 。

Amazon RDS PostgreSQL

1. 在源数据库上安装 pglogical 扩展程序。

   如需了解详情，请参阅 Amazon RDS 文档中的将 PostgreSQL 扩展程序与 Amazon RDS for PostgreSQL 搭配使用。

2. 使用 参数组配置源实例。

   1. 创建新的参数组。在参数组中：
   • 确保 shared_preload_libraries 参数包含 pglogical。
   • 将 rds.logical_replication 参数设置为 1。这将在“逻辑”级别启用 WAL 日志。
   • 将 wal_sender_timeout 参数设置为 0。这会停用用于终止非活跃复制连接的超时机制。

   • 设置 max_replication_slots 参数。此参数定义了源实例可以支持的复制槽数量上限。必须至少将其设置为预期连接的订阅数，并预留一部分进行表同步。

     Database Migration Service 要求为每个迁移的数据库（即源实例下的所有数据库）提供一个槽。

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

     此参数的默认值为 10 。

   • 将 max_wal_senders 参数设置为至少与 max_replication_slots 加上已在实例上使用的发送器数量相同。

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

     此参数的默认值为 10 。

   • 将 max_worker_processes 源参数设置为至少与 Database Migration Service 将要迁移的数据库数量（即源实例下的所有数据库）加上已在实例上使用的 max_worker_processes 数量相同。如果您计划使用调整后的数据转储并行设置， 请务必增加工作器进程的数量，并 在创建迁移作业时通过 运行迁移作业测试来验证您的配置。

     此参数的默认值为 8 。

   2. 将参数组附加到实例。如果您要创建新实例，则可以在其他配置 下找到此选项。

      否则，请修改实例以附加参数组。

3. 如需应用配置更改，请重启源实例 。

注意：pglogical 扩展程序可以在源实例上以纯文本形式记录凭据。此行为是由扩展程序本身引起的，与 Database Migration Service 或 Cloud SQL 无关。

Cloud SQL for PostgreSQL

通过配置以下标志，为源数据库启用逻辑复制和解码：

本部分中的所有设置都是使用 Cloud SQL 中的标志进行配置的。 如需在 Cloud SQL 中启用标志，请参阅 配置数据库标志。

1. 将 cloudsql.logical_decoding 和 cloudsql.enable_pglogical 标志设置为 on。

2. 设置 max_replication_slots 标志。此标志定义了源实例可以支持的 复制槽数量上限。必须至少将其设置为预期连接的 订阅数，并预留一部分进行表 同步。

   Database Migration Service 要求为每个迁移的数据库（即源实例下的所有数据库）提供一个槽。

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

   此标志的默认值为 10 。

3. 将 max_wal_senders 标志设置为至少与 max_replication_slots 加上已在实例上使用的发送器数量相同。

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

   此标志的默认值为 10 。

4. 将 max_worker_processes 源标志设置为至少与 Database Migration Service 将要迁移的数据库数量（即 源实例下的所有数据库）加上已在实例上使用的 max_worker_processes 数量相同。 如果您计划使用调整后的数据转储并行 设置，请务必增加工作器进程的数量，并在创建迁移作业时运行迁移作业测试来验证 您的配置。

   此标志的默认值为 8 。

5. 将 wal_sender_timeout 参数设置为 0。 0 值可停用用于终止 非活跃复制连接 的超时机制。

6. 重启源实例 ，以便您对标志的配置更改生效。

为 9.6 之前的 PostgreSQL 版本启用复制延迟监控

如果您要从低于 9.6 的 PostgreSQL 版本进行迁移，则复制延迟指标默认不可用。您可以使用以下备选方法来跟踪此指标，以便在升级数据库时确保将停机时间控制在最短：

• 方法 1：启用 Database Migration Service，通过授予对特定查询的访问权限来跟踪复制 延迟。使用具有 SUPERUSER 权限的用户执行以下操作：

  1. 定义以下函数，以允许 Database Migration Service 查询复制延迟。

     CREATE OR REPLACE FUNCTION pg_stat_replication_user()
     RETURNS TABLE (
     pid               integer                  ,
     usesysid          oid                      ,
     username          name                    ,
     application_name  text                     ,
     client_addr       inet                     ,
     client_hostname   text                     ,
     client_port       integer                  ,
     backend_start     timestamp with time zone ,
     backend_xmin      xid                      ,
     state             text                     ,
     sent_location     pg_lsn                   ,
     write_location    pg_lsn                   ,
     flush_location    pg_lsn                   ,
     replay_location   pg_lsn                   ,
     sync_priority     integer                  ,
     sync_state        text
     )
     LANGUAGE SQL
     SECURITY DEFINER
     AS $$
      SELECT *
      FROM pg_catalog.pg_stat_replication;
     $$;
     

  2. 运行以下命令，向 USER 授予 EXECUTE 权限：

     1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
     2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

• 方法 2：直接将 SUPERUSER 权限授予用于连接到源实例的 USER。这样，Database Migration Service 就可以直接读取复制延迟。

• 方法 3：使用以下查询独立跟踪复制延迟：

  对于低于 10 的 PostgreSQL 版本，请以 superuser 身份运行此命令。

      SELECT current_timestamp, application_name,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag
      FROM pg_stat_replication
      WHERE application_name like 'cloudsql%';
    

  在此方法中，Database Migration Service 不会反映图表或 API 响应中的复制延迟指标。