实时迁移

实时迁移是一种端到端解决方案，可将数据库模式和数据复制到您的目标 Timescale Cloud 服务，然后将源数据库中的数据库活动实时复制到目标服务。实时迁移使用 PostgreSQL 逻辑解码功能并利用 pgcopydb。

您可以使用实时迁移 Docker 镜像将 100GB-10TB+ 的数据无缝迁移到 Timescale Cloud 服务，停机时间仅需几分钟。

重要提示

如果您要迁移超过 400GB 的数据，请创建 Timescale 控制台支持请求，或发送电子邮件至 support@timescale.com 说明您要迁移多少数据。我们将为您预配置 Timescale Cloud 实例。

最佳实践是在以下情况下使用实时迁移

• 修改您的应用程序逻辑以执行双写是一项重要的工作。

• 插入工作负载不超过每秒 20,000 行，并且插入是批处理的。

  对于更大的工作负载，请使用双写和回填。

• 您的源数据库

  • 在未压缩的时序数据上使用 UPDATE 和 DELETE 语句。

    实时迁移不支持复制压缩数据上的 INSERT/UPDATE/DELETE 语句。

  • 具有带主键的大型繁忙表。

  • 没有很多 UPDATE 或 DELETE 语句。

此页面向您展示如何使用实时迁移 Docker 镜像将数据从自托管数据库移动到 Timescale Cloud 服务。

最佳实践是使用与您的 Timescale Cloud 服务位于同一区域的 Ubuntu EC2 实例 来移动数据。也就是说，您在其上运行命令以将数据从源数据库移动到目标 Timescale Cloud 服务的机器。

在移动数据之前

• 创建目标 Timescale Cloud 服务。

  每个 Timescale Cloud 服务都有一个支持最流行的扩展的单个数据库。 Timescale Cloud 服务不支持表空间，并且没有与服务关联的超级用户。最佳实践是创建至少具有 8 个 CPU 的 Timescale Cloud 服务，以获得更流畅的体验。更高规格的实例可以显着缩短整体迁移窗口。

• 为了确保在迁移过程中维护不会运行，最佳实践是调整维护窗口。

• 在您的迁移机器上安装 Docker。

  此机器需要足够的空间来存储数据复制期间发生的缓冲更改。此空间与迁移期间写入 Timescale Cloud 服务的新未压缩数据量成正比。一般的经验法则是 100GB 到 500GB 之间。此 EC2 实例的 CPU 规格应与您的 Timescale Cloud 实例的 CPU 规格相匹配，以获得最佳性能。例如，如果您的 Timescale Cloud 实例具有 8 核 CPU 配置，则您的 EC2 实例也应具有 8 核 CPU。

• 在开始实时迁移之前，请阅读常见问题解答。

要将数据从自托管数据库移动到 Timescale Cloud 服务

完成！您的数据现在已在您的 Timescale Cloud 服务中。

本节向您展示如何解决使用实时迁移时经常遇到的问题。

当关系在执行 snapshot 命令后被删除时，可能会发生这种情况。关系可以是表、索引、视图或物化视图。当您看到此错误时

• 在迁移过程中，不要在源数据库上执行任何显式的 DDL 操作。

• 如果您要从自托管的 TimescaleDB 或 MST 迁移，请在完成迁移之前禁用源数据库上的块保留策略。

当连接数耗尽目标 Timescale Cloud 服务中定义的 max_connections 时，可能会发生这种情况。默认情况下，实时迁移在源上需要大约 ~6 个连接，在目标上需要大约 ~12 个连接。

当您迁移大量涉及聚合的数据时，或者有许多物化视图需要时间才能完成物化时，这可能是由于初始数据迁移结束时发生的 REFRESH MATERIALIZED VIEWS 造成的。

要解决此问题

1. 查看目标 Timescale Cloud 服务上正在发生的事情

   psql $TARGET -c "select * from pg_stat_activity where application_name ilike '%pgcopydb%';"

   复制

2. 当您运行 migrate 时，添加以下标志以排除要物化的特定物化视图

   --skip-table-data <matview1> <matview2>”

   复制

3. 当 migrate 完成后，手动刷新您排除的物化视图。

如果迁移由于故障而停止，例如源数据库或目标数据库配置错误，您可能需要从头开始重新启动迁移。在这种情况下，您可以通过将 --drop-if-exists 标志与 migrate 命令一起使用来重用为迁移创建的原始 Timescale 目标实例。

此标志确保删除先前迁移创建的现有目标对象，从而使迁移能够顺利进行。

这是一个重新启动迁移的示例命令

docker run --rm -it --name live-migration-migrate \
    -e PGCOPYDB_SOURCE_PGURI=$SOURCE \
    -e PGCOPYDB_TARGET_PGURI=$TARGET \
    --pid=host \
    -v ~/live-migration:/opt/timescale/ts_cdc \
    timescale/live-migration:latest migrate --drop-if-exists

复制

这种方法为迁移过程提供了全新的开始，同时重用了现有的目标实例。

如果您在使用实时迁移后在云提供商控制台上遇到“非活动或滞后的复制槽”警告，则可能是由于实时迁移工具在源数据库上创建的持久复制槽所致。

要清理与实时迁移关联的资源，请使用以下命令

docker run --rm -it --name live-migration-clean \
    -e PGCOPYDB_SOURCE_PGURI=$SOURCE \
    -e PGCOPYDB_TARGET_PGURI=$TARGET \
    --pid=host \
    -v ~/live-migration:/opt/timescale/ts_cdc \
    timescale/live-migration:latest clean --prune

复制

--prune 标志用于删除 ~/live-migration 目录中迁移过程所需的临时文件。重要的是要注意，执行 clean 命令意味着您无法恢复中断的实时迁移。

由于从各种托管服务提供商转储密码时出现问题，实时迁移会在不迁移密码的情况下迁移角色。您必须手动迁移密码。

实时迁移不会迁移表权限。完成实时迁移后

1. 授予所有角色给 tsdbadmin。

   psql -d $SOURCE -t -A -c "SELECT FORMAT('GRANT %I TO tsdbadmin;', rolname) FROM 
   pg_catalog.pg_roles WHERE rolname not like 'pg_%' AND rolname != 'tsdbadmin' 
   AND NOT rolsuper" | psql -d $TARGET -f -

   复制
2. 在您的迁移机器上，编辑 /tmp/grants.psql 以匹配源数据库上的表权限。

   pg_dump --schema-only --quote-all-identifiers 
   --exclude-schema=_timescaledb_catalog --format=plain --dbname "$SOURCE" | grep 
   "(ALTER.*OWNER.*|GRANT|REVOKE)"  > /tmp/grants.psql

   复制
3. 在您的目标 Timescale Cloud 服务上运行 grants.psql。

   psql -d $TARGET -f /tmp/grants.psql

   复制

1. 转到 Timescale 云控制台 -> 洞察选项卡，找到耗时较长的查询
2. 如果查询是 UPDATE/DELETE，请确保 WHERE 子句中使用的列具有必要的索引。
3. 如果查询是对已转换为超表的表执行的 UPDATE/DELETE，请确保源上的 REPLICA IDENTITY（默认为主键）与目标主键兼容。如果不是，请通过包含超表分区列在源数据库上创建 UNIQUE 索引，并将其作为 REPLICA IDENTITY。此外，在目标上创建相同的 UNIQUE 索引。

当由于内存分配超出安全限制而触发内存不足 (OOM) 保护时，会发生此错误。当多个并发连接到 TimescaleDB 实例执行内存密集型操作时，通常会发生这种情况。例如，在实时迁移期间，当同时创建大型索引时，可能会发生此错误。

实时迁移工具包含重试机制来处理此类错误。但是，频繁的 OOM 崩溃可能会显着延迟迁移过程。

可以使用以下方法之一来避免 OOM 错误

1. 升级到更高内存规格的实例：为了缓解内存限制，请考虑使用具有更高规格的 TimescaleDB 实例，例如具有 8 个 CPU 和 32 GB RAM（或更多）的实例。更高的内存容量可以处理更大的工作负载并减少 OOM 错误的发生率。

2. 降低并发性：如果升级实例不可行，您可以使用迁移命令中的 --index-jobs=<value> 标志来降低索引迁移过程的并发性。默认情况下，--index-jobs 的值与 GUC max_parallel_workers 匹配。降低此值会减少迁移期间的内存使用量，但可能会增加总迁移时间。

通过采取这些步骤，您可以防止 OOM 错误并确保更顺畅的 TimescaleDB 迁移体验。