配置来源

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。
• Amazon Aurora 10.11+、11.6+、12.4+、13.3+、14.6+、15.2+、16、17。
• 自行管理的 PostgreSQL（在本地或由您完全控制的任何云端虚拟机上）9.4、9.5、9.6、10、11、12、13、14、15、16、17。
• Cloud SQL for PostgreSQL 9.6、10、11、12、13、14、15、16、17。
• Microsoft Azure Database for PostgreSQL 弹性服务器：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. 针对要迁移的每个数据库中的所有架构（信息架构以及以“pg_”开头的架构除外），运行 GRANT USAGE on SCHEMA SCHEMA to USER。
   2. GRANT USAGE on SCHEMA pglogical to PUBLIC;。
   3. 针对所有数据库运行 GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER，以便从源数据库获取复制信息。
   4. 针对要迁移的每个数据库中的所有架构（信息架构以及以“pg_”开头的架构除外），运行 GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER。
   5. 针对要迁移的每个数据库中的所有架构（信息架构以及以“pg_”开头的架构除外），运行 GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER。
   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。这会在“logical”级别启用 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：

   ALTER SYSTEM SET 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 响应中的复制延迟指标。