Timescale Cloud:性能、扩展、企业级
自托管产品
MST
实时迁移是一种端到端解决方案,可将数据库模式和数据复制到目标 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
。
要解决此问题:
查看目标 Timescale Cloud 服务上正在发生什么
psql $TARGET -c "select * from pg_stat_activity where application_name ilike '%pgcopydb%';"当您运行
migrate
命令时,添加以下标志以排除特定物化视图的物化:--skip-table-data <matview1> <matview2>”当
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
命令意味着您无法恢复中断的实时迁移。
由于从各种托管服务提供商导出密码存在问题,实时迁移在迁移角色时不包含密码。您必须手动迁移密码。
实时迁移不迁移表权限。完成实时迁移后:
- 将所有角色授予
tsdbadmin
。psql -d $SOURCE -t -A -c "SELECT FORMAT('GRANT %I TO tsdbadmin;', rolname) FROMpg_catalog.pg_roles WHERE rolname not like 'pg_%' AND rolname != 'tsdbadmin'AND NOT rolsuper" | psql -d $TARGET -f - - 在您的迁移机器上,编辑
/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 - 在您的目标 Timescale Cloud 服务上运行
grants.psql
。psql -d $TARGET -f /tmp/grants.psql
- 前往 Timescale 云控制台 -> Insights 标签页,找到耗时较长的查询
- 如果查询是 UPDATE/DELETE,请确保 WHERE 子句中使用的列具有必要的索引。
- 如果查询是对已转换为超表的表进行 UPDATE/DELETE 操作,请确保源上的 REPLICA IDENTITY(默认为主键)与目标主键兼容。如果不兼容,请通过包含超表分区列在源数据库中创建唯一索引并将其设置为 REPLICA IDENTITY。同时,在目标上创建相同的唯一索引。
当内存分配超出安全限制导致内存不足(OOM)保护被触发时,会发生此错误。这通常发生在 TimescaleDB 实例的多个并发连接正在执行内存密集型操作时。例如,在实时迁移过程中,当同时创建大型索引时,可能会出现此错误。
实时迁移工具包含重试机制来处理此类错误。然而,频繁的 OOM 崩溃可能会显著延迟迁移过程。
可以使用以下方法之一避免 OOM 错误:
升级到更高内存规格的实例:为了缓解内存限制,请考虑使用更高规格的 TimescaleDB 实例,例如具有 8 个 CPU 和 32 GB RAM(或更多)的实例。更高的内存容量可以处理更大的工作负载并减少 OOM 错误的发生。
降低并发性:如果升级实例不可行,您可以使用迁移命令中的
--index-jobs=<value>
标志来降低索引迁移过程的并发性。默认情况下,--index-jobs
的值与 GUC max_parallel_workers 匹配。降低此值可减少迁移期间的内存使用,但可能会增加总迁移时间。
通过采取这些步骤,您可以防止 OOM 错误并确保 TimescaleDB 的迁移体验更加顺畅。
关键词