配置来源

MySQL   |  PostgreSQL   |  PostgreSQL 到 AlloyDB

概览

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

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、15、16、17
• 自行管理的 PostgreSQL（在本地或由您完全控制的任何云虚拟机上）9.4、9.5、9.6、10、11、12、13、14、15、16、17
• Cloud SQL 9.6、10、11、12、13、14、15、16、17

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

配置源实例

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

1. 源实例必须包含 postgres 数据库。如果您没有此数据库，请创建一个。
2. 在源实例上安装 pglogical 软件包，并确保它包含在 shared_preload_libraries 变量中。
   1. 请参阅在源实例上安装 pglogical 软件包（适用于您的环境）。

配置源数据库

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

• 对于本地源：模板数据库 template0 和 template1
• 对于 Amazon RDS 源：template0、template1 和 rdsadmin
• 对于 Cloud SQL 源：模板数据库 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 软件包，包括 max_replication_slots、max_wal_senders 和 max_worker_processes 参数的配置。 您还可以在创建迁移作业时运行迁移作业测试，以获取这些参数的正确值。在此测试期间，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. 如需应用配置更改，请重启源实例 。

Amazon RDS PostgreSQL

1. 在源数据库上安装 pglogical 扩展程序。 如需了解详情，请参阅 Amazon RDS 文档中的将 PostgreSQL 扩展程序与 Amazon RDS for PostgreSQL 搭配使用。

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

   • 创建新的参数组。在参数组中：
   • 确保 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 数量之外，应至少将 max_worker_processes 源参数设置为 Database Migration Service 将要迁移的数据库数量（即源实例下的所有数据库）。如果您计划使用调整后的数据转储并行设置， 请务必增加工作器进程的数量，并 在创建迁移作业时通过 运行迁移作业测试来验证您的配置。

     此参数的默认值为 8 。

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

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

注意：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 数量之外，应至少将 max_worker_processes 源标志设置为 Database Migration Service 将要迁移的数据库数量（即源实例下的所有数据库）。如果您计划使用调整后的数据转储并行设置 ，请为每个连接考虑两个额外的工作器进程 （最多 20 个工作器）。

   此标志的默认值为 8 。

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

为低于 9.6 的 PostgreSQL 版本启用复制延迟监控

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

1. 方法 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. 方法 2：直接将 SUPERUSER 权限授予用于连接到源实例的 USER。这样，Database Migration Service 就可以直接读取复制延迟。

3. 方法 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 响应中的复制延迟指标。