Timescale Cloud:性能、扩展、企业级

自托管产品

MST

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

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

重要

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

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

  • 修改您的应用程序逻辑以执行双写操作需要大量工作。

  • 插入工作负载不超过每秒 20,000 行,且插入是批量进行的。

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

  • 您的源数据库:

    • 对未压缩的时序数据使用 UPDATEDELETE 语句。

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

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

    • 没有太多 UPDATEDELETE 语句。

本页面向您展示如何使用实时迁移 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 的迁移体验更加顺畅。

关键词

在此页面上发现问题?报告问题 或 编辑此页面 在 GitHub。