实时迁移

实时迁移是一种端到端解决方案，可将数据库模式和数据复制到目标 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 进行迁移，请在完成迁移之前禁用源数据库上的 chunk 保留策略。

这可能发生在目标 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 完成后，手动刷新您排除的物化视图。

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

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

注意：此标志还要求您在目标上手动重新创建 TimescaleDB 扩展。

以下是重新启动迁移的示例命令序列：

psql $TARGET -c "DROP EXTENSION timescaledb CASCADE"

psql $TARGET -c 'CREATE EXTENSION timescaledb VERSION "<desired version>"'

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 云控制台 -> Insights 标签页，找到耗时较长的查询
2. 如果查询是 UPDATE/DELETE，请确保 WHERE 子句中使用的列具有必要的索引。
3. 如果查询是对已转换为超表的表进行 UPDATE/DELETE 操作，请确保源上的 REPLICA IDENTITY（默认为主键）与目标主键兼容。如果不兼容，请通过包含超表分区列在源数据库中创建唯一索引并将其设置为 REPLICA IDENTITY。同时，在目标上创建相同的唯一索引。

当内存分配超出安全限制导致内存不足（OOM）保护被触发时，会发生此错误。这通常发生在 TimescaleDB 实例的多个并发连接正在执行内存密集型操作时。例如，在实时迁移过程中，当同时创建大型索引时，可能会出现此错误。

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

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

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

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

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