Timescale Cloud:性能、规模、企业级

自托管产品

MST

双写和回填是一种将应用程序数据同时写入两个数据库的方法,并提供工具和指导,将现有数据从一个数据库移动到另一个数据库。它专门针对主要为仅追加时间序列数据的情况而设计并依赖于此类数据。因此,它带有一些实时迁移不具备的注意事项和先决条件(双写和回填不支持对您的数据执行 `UPDATE` 或 `DELETE` 语句)。此外,它要求您更改应用程序的摄取管道。

timescaledb-backfill 工具是一个命令行实用程序,旨在通过将历史数据从一个数据库复制到另一个数据库(“回填”)来支持从 Timescale 实例进行的迁移。timescaledb-backfill 直接高效地复制超表和连续聚合块,无需中间存储,也无需将块从列存储转换为行存储。它以事务方式操作,确保在整个迁移过程中的数据完整性。它旨在用于双写和回填迁移过程中。

  • 该工具仅支持超表的回填。在使用此工具之前,模式迁移和非超表迁移应单独处理。
  • 该工具针对仅追加的工作负载进行了优化。其他场景可能无法完全支持。
  • 为防止连续聚合用不完整的数据进行刷新,应关闭针对将要回填的表的任何刷新和保留策略。

该工具在靠近目标数据库的实例中执行时性能最佳。理想情况是与 Timescale 服务位于同一区域的 EC2 实例。请使用基于 x86_64 的 Linux 发行版。

当运行 timescaledb-backfill 的实例准备就绪后,登录并下载该工具的二进制文件

wget https://#/releases/timescaledb-backfill-x86_64-linux.tar.gz
tar xf timescaledb-backfill-x86_64-linux.tar.gz
sudo mv timescaledb-backfill /usr/local/bin/

timescaledb-backfill 工具提供四个主要命令:stage(阶段)、copy(复制)、verify(验证)和 clean(清理)。工作流程包括创建任务、复制块、验证数据完整性以及迁移完成后清理管理模式。

注意

在迁移上下文中,您现有的生产数据库被称为“源”数据库,而您计划将数据迁移到的新 Timescale 数据库被称为“目标”数据库。

  • Stage 命令: 用于根据指定的完成点(--until)为超表块创建复制任务。如果未指定起始点(--from),则数据将从开始时复制到完成点(--until)。可以使用可选的过滤器(--filter)来优化目标超表和连续聚合的暂存。

    timescaledb-backfill stage --source $SOURCE --target $TARGET --until '2016-01-02T00:00:00'

    可以通过提供过滤选项来控制要包含在暂存中的表

    --filter:此选项接受一个 POSIX 正则表达式,用于匹配带模式限定的超表名称或连续聚合视图名称。只有与过滤器匹配的超表和/或连续聚合才会被暂存。

    默认情况下,过滤器只包含匹配的对象,不考虑对象之间的依赖关系。根据预期目的,这对于连续聚合可能会有问题,因为它们形成了一个依赖层次结构。此行为可以通过级联选项进行修改。

    例如,假设在一个名为 raw_data(都在 public 模式中)的底层超表中,数据按小时、每天和每周进行汇总的连续聚合层次结构。这可能如下所示

    raw_data -> hourly_agg -> daily_agg -> monthly_agg

    如果应用过滤器 --filter='^public\.raw_data$',则不会暂存来自连续聚合的任何数据。如果应用过滤器 --filter='^public\.daily_agg$',则只暂存连续聚合 daily_agg 中的具体化数据。

    --cascade-up:启用此选项后,它会确保任何依赖于过滤对象的连续聚合都包含在暂存过程中。之所以称为“级联向上”,是因为它会向上级联层次结构。以上述示例为例,如果应用过滤器 --filter='^public\.raw_data$' --cascade up,则 raw_datahourly_aggdaily_aggmonthly_agg 中的数据都会被暂存。

    --cascade-down:启用此选项后,它会确保过滤对象所依赖的任何对象都包含在暂存过程中。之所以称为“级联向下”,是因为它会向下级联层次结构。以上述示例为例,如果应用过滤器 --filter='^public\.daily_agg$' --cascade-down,则 daily_agghourly_aggraw_data 中的数据都会被暂存。

    --cascade-up--cascade-down 选项可以组合使用。以上述示例为例,如果应用过滤器 --filter='^public\.daily_agg$' --cascade-up --cascade-down,则示例场景中的所有对象数据都将被暂存。

    timescaledb-backfill stage --source $SOURCE --target $TARGET \
    --until '2016-01-02T00:00:00' \
    --filter '^public\.daily_agg$' \
    --cascade-up \
    --cascade-down
  • Copy 命令: 处理暂存阶段创建的任务,并将相应的超表块复制到目标 Timescale 服务。

    timescaledb-backfill copy --source $SOURCE --target $TARGET

    除了 --source--target 参数外,copy 命令还接受一个可选参数

    --parallelism 指定将并行运行的 COPY 作业数量,默认值为 8。理想情况下,它应设置为源数据库和目标数据库拥有的核心数量,并且是决定源数据库负载量以及数据从源数据库传输到目标数据库速度的最重要参数。

  • Verify 命令: 检查源和目标块数据之间是否存在差异。它比较每个块表的计数结果,以及每列的计数、最大值、最小值和总和值(如果适用,取决于列数据类型)。

    timescaledb-backfill verify --source $SOURCE --target $TARGET

    除了 --source--target 参数外,verify 命令还接受一个可选参数

    --parallelism 指定将并行运行的验证作业数量,默认值为 8。理想情况下,它应设置为源数据库和目标数据库拥有的核心数量,并且是决定验证期间源数据库和目标数据库负载量以及验证完成所需时间的最重要参数。

  • 刷新连续聚合命令: 刷新目标系统的连续聚合。它涵盖从目标系统上次刷新到源系统上次刷新的期间,解决了连续聚合超出刷新策略覆盖范围而过时的问题。

    timescaledb-backfill refresh-caggs --source $SOURCE --target $TARGET

    要刷新连续聚合,该命令会为所有匹配的连续聚合执行以下 SQL 语句

    CALL refresh_continuous_aggregate({CAGG NAME}, {TARGET_WATERMARK}, {SOURCE_WATERMARK})

    可以通过提供过滤选项来控制要刷新的连续聚合

    --filter:此选项接受一个 POSIX 正则表达式,用于匹配带模式限定的超表连续聚合视图名称。

    默认情况下,过滤器只包含匹配的对象,不考虑对象之间的依赖关系。根据预期目的,这可能会有问题,因为连续聚合形成一个依赖层次结构。此行为可以通过级联选项进行修改。

    例如,假设在一个名为 raw_data(都在 public 模式中)的底层超表中,数据按小时、每天和每周进行汇总的连续聚合层次结构。这可能如下所示

    raw_data -> hourly_agg -> daily_agg -> monthly_agg

    如果应用过滤器 --filter='^public\.daily_agg$',则只会更新连续聚合 daily_agg 中的具体化数据。但是,这种方法可能会导致潜在问题。例如,如果 hourly_agg 未更新,则 daily_agg 也不会更新,因为它需要 hourly_agg 中缺少的数据。此外,务必记住在某个时候刷新 monthly_agg,以确保其数据保持最新。在这两种情况下,如果策略未涵盖所需的整个期间,则仅依赖刷新策略可能会导致数据缺失。

    --cascade-up:启用此选项后,它会确保任何依赖于过滤对象的连续聚合都得到刷新。之所以称为“级联向上”,是因为它会向上级联层次结构。以上述示例为例,如果应用过滤器 --filter='^public\.daily_agg$' --cascade up,则 hourly_aggdaily_aggmonthly_agg 将被刷新。

    --cascade-down:启用此选项后,它会确保过滤对象所依赖的任何连续聚合都得到刷新。之所以称为“级联向下”,是因为它会向下级联层次结构。以上述示例为例,如果应用过滤器 --filter='^public\.daily_agg$' --cascade-down,则 daily_agghourly_agg 中的数据将被刷新。

    --cascade-up--cascade-down 选项可以组合使用。以上述示例为例,如果应用过滤器 --filter='^public\.daily_agg$' --cascade-up --cascade-down,则所有连续聚合都将被刷新。

  • Clean 命令: 在成功完成迁移后,移除用于存储任务的管理模式(__backfill)。

    timescaledb-backfill clean --target $TARGET
  • 使用过滤器和截止日期进行回填

    timescaledb-backfill stage --source $SOURCE_DB --target $TARGET_DB \
    --filter '.*\.my_table.*' \
    --until '2016-01-02T00:00:00'
    timescaledb-backfill copy --source $SOURCE --target $TARGET
    timescaledb-backfill refresh-caggs --source $SOURCE --target $TARGET
    timescaledb-backfill verify --source $SOURCE --target $TARGET
    timescaledb-backfill clean --target $TARGET
  • 运行多个阶段,使用不同的过滤器和截止日期

    timescaledb-backfill stage --source $SOURCE --target $TARGET \
    --filter '^schema1\.table_with_time_as_timestampz$' \
    --until '2015-01-01T00:00:00'
    timescaledb-backfill stage --source $SOURCE --target $TARGET \
    --filter '^schema1\.table_with_time_as_bigint$' \
    --until '91827364'
    timescaledb-backfill stage --source $SOURCE --target $TARGET \
    --filter '^schema2\..*' \
    --until '2017-01-01T00:00:00'
    timescaledb-backfill copy --source $SOURCE --target $TARGET
    timescaledb-backfill refresh-caggs --source $SOURCE --target $TARGET
    timescaledb-backfill verify --source $SOURCE --target $TARGET
    timescaledb-backfill clean --target $TARGET
  • 使用起始和截止时间回填特定时间段

timescaledb-backfill stage --source $SOURCE_DB --target $TARGET_DB \
--from '2015-01-02T00:00:00' \
--until '2016-01-02T00:00:00'
timescaledb-backfill copy --source $SOURCE --target $TARGET
timescaledb-backfill clean --target $TARGET
  • 刷新连续聚合层次结构
timescaledb-backfill refresh-caggs --source $SOURCE --target $TARGET \
--filter='^public\.daily_agg$' --cascade-up --cascade-down

可以通过向进程发送中断信号 (SIGINT) 来安全地停止 copy 命令。这可以通过在工具当前运行的终端中使用 Ctrl-C 键盘快捷键来实现。

当工具收到第一个信号时,它将其解释为优雅关闭的请求。然后它通知复制工作程序,一旦完成当前正在处理的块的复制,它们就应该退出。根据块的大小,这可能需要数分钟才能完成。

当收到第二个信号时,它会强制工具立即关闭,中断所有正在进行的工作。由于该工具使用事务,因此在使用强制关闭时不存在数据不一致的风险。

优雅关闭会等待正在进行的块完成复制,而强制关闭则会回滚正在进行的复制事务。复制到这些块中的任何数据都将丢失,但数据库将处于事务一致状态,并且回填过程可以安全地恢复。

每个将要回填的超表块都在目标数据库的 __backfill.task 表中存储有相应的任务。您可以使用此信息来检查回填的进度

select
hypertable_schema,
hypertable_name,
count(*) as total_chunks,
count(worked) as finished_chunks,
count(worked is null) pending_chunks
from __backfill.task
group by
1,
2

关键词

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