常见问题与故障排除

实时迁移工具目前处于实验阶段。您可能会遇到以下不足

• 实时迁移尚不支持可变列存压缩（对列存中的数据进行 `INSERT`、`UPDATE`、`DELETE` 操作）。
• 默认情况下，包含 `NaN` / `+Inf` / `-Inf` 值的数字字段无法正确复制，将被转换为 `NULL`。有可用的解决方案，但默认未启用。

如果您遇到任何问题，请在浪费时间调试问题之前提交支持请求。

您可以直接从 Timescale 控制台，或发送电子邮件至 support@timescale.com。

实时迁移涉及多个后台进程来管理迁移的不同阶段。这些进程的日志有助于排除意外行为。您可以在 `/logs` 目录中找到这些日志。

当您将自托管或TimescaleDB 托管服务 (MST) 数据库迁移到 Timescale 时，源数据库和目标 Timescale 服务 必须运行相同版本的 TimescaleDB。

在开始实时迁移之前

1. 检查源数据库和目标 Timescale 服务上运行的 TimescaleDB 版本

   select extversion from pg_extension where extname = 'timescaledb';

   复制

2. 如果源数据库上的 TimescaleDB 版本低于您的 Timescale 服务，您可以选择

   • 降级：在您的 Timescale 服务上重新安装与源数据库匹配的 TimescaleDB 旧版本

     1. 连接到您的 Timescale 服务并检查可用的 TimescaleDB 版本

        SELECT version FROM pg_available_extension_versions WHERE name = 'timescaledb' ORDER BY 1 DESC;

        复制

     2. 如果 TimescaleDB 的可用版本与您的源数据库匹配

        1. 从您的 Timescale 服务中卸载 TimescaleDB

           DROP EXTENSION timescaledb;

           复制

        2. 重新安装正确版本的 TimescaleDB

           CREATE EXTENSION timescaledb VERSION '<version>';

           复制
        

        注意

        创建 TimescaleDB 扩展时，您可能需要使用 `psql -X` 重新连接到您的 Timescale 服务。

   • 升级：对于自托管数据库，升级 TimescaleDB 以匹配您的 Timescale 服务。

实时迁移在复制过程中从源数据库接收到 `UPDATE` 语句后，如果无法确定应更新哪些特定行，就会记录 `WARNING: no tuple identifier for UPDATE in table` 警告。这发生在源数据库中接收 `UPDATE` 语句的表缺少 `PRIMARY KEY` 或 `REPLICA IDENTITY` 设置时。为了使实时迁移成功复制 `UPDATE` 和 `DELETE` 语句，表必须预先设置 `PRIMARY KEY` 或 `REPLICA IDENTITY`。

如果您的 PostgreSQL 表使用原生分区，在根（父）表上设置 `REPLICA IDENTITY` 不会自动将其应用于分区子表。您必须手动在每个分区子表上设置 `REPLICA IDENTITY`。

实时迁移不支持从只读或故障转移副本进行复制。您必须提供直接指向源数据库的连接字符串以进行实时迁移。

实时迁移不支持连接池器。您必须提供直接指向源数据库和目标数据库的连接字符串，以使实时迁移顺利进行。

不可以，Timescale Cloud 不能用作实时迁移的源数据库。

目前，实时迁移不支持排除架构或表不参与复制，但此功能预计将在未来的版本中添加。不过，可以使用 `--skip-table-data` 标志来跳过表数据。有关更多信息，请参阅 `migrate` 子命令下的帮助文本。

Timescale 平台自动管理底层磁盘卷。由于平台限制，每六小时只能调整一次磁盘大小。根据您复制数据的速度，您可能会受到此限制的影响。受影响的实例无法接受新数据并报错：`FATAL: terminating connection due to administrator command`。

如果您打算将超过 400 GB 的数据迁移到 Timescale，请提交支持请求，要求在您的 Timescale 实例中预分配所需的存储空间。

您可以直接从 Timescale 控制台，或发送电子邮件至 support@timescale.com。

当 `pg_dump` 启动时，它会对所有要转储的表获取 `ACCESS SHARE` 锁。这确保了在 `pg_dump` 能够删除表之前，表不会被删除。此操作的副作用是，任何尝试对表获取 `ACCESS EXCLUSIVE` 锁的查询都将被 `ACCESS SHARE` 锁阻塞。

许多 Timescale 内部进程需要获取 `ACCESS EXCLUSIVE` 锁以确保数据的一致性。以下是可能受影响操作的不完全列表

• 将数据块转换为列存/行存并转换回来
• 连续聚合刷新（2.12 版之前）
• 创建带外键的超表，截断超表
• 在超表上启用 hypercore
• 删除数据块

上述最可能的影响是，保留策略、列存压缩策略和连续聚合刷新策略的后台作业在 `pg_dump` 命令执行期间被阻塞。这可能会对您的数据库性能造成意想不到的后果。

当使用 `pg_dump` 目录格式时，可以使用并发来通过多个连接到源数据库来转储数据。这会加快转储过程。由于存在多个连接，`pg_dump` 可能会陷入死锁情况。当它检测到死锁时，它会中止转储。

原则上，任何对表获取 `ACCESS EXCLUSIVE` 锁的查询都会导致此类死锁。如上所述，一些常见的获取 `ACCESS EXCLUSIVE` 锁的操作有

• 保留策略
• 列存压缩策略
• 连续聚合刷新策略

如果您仍然希望使用并发，请在运行 `pg_dump` 之前关闭源数据库中的所有后台作业，并在转储完成后重新开启它们。如果转储过程所需时间超过连续聚合刷新策略的窗口，您必须手动在正确的时间范围内刷新连续聚合。有关更多信息，请查阅刷新策略文档。

关闭作业

SELECT public.alter_job(id::integer, scheduled=>false)
FROM _timescaledb_config.bgw_job
WHERE id >= 1000;

复制

开启作业

SELECT public.alter_job(id::integer, scheduled=>true)
FROM _timescaledb_config.bgw_job
WHERE id >= 1000;

复制

如果 `pg_dump` 和 `pg_restore` 使用目录格式，可以采用并发来加速此过程。遗憾的是，并发加载 `timescaledb_catalog` 架构中的表会导致错误。此外，`tsdbadmin` 用户没有足够的权限来关闭此架构中的触发器。为了解决此限制，请串行加载此架构，然后并发加载数据库的其余部分。

# first, serially load JUST the _timescaledb_catalog
pg_restore -d "$TARGET" \
    --format=directory \
    --schema='_timescaledb_catalog' \
    --exit-on-error \
    --no-tablespaces \
    --no-owner \
    --no-privileges \
    dump

# next, concurrently load everything EXCEPT the _timescaledb_catalog 
pg_restore -d "$TARGET" \
    --format=directory \
    --jobs=8 \
    --exclude-schema='_timescaledb_catalog' \
    --exit-on-error \
    --disable-triggers \
    --no-tablespaces \
    --no-owner \
    --no-privileges \
    dump

复制

_timescaledb_config.bgw_jobs 表用于管理后台作业。这包括自定义作业、列存压缩策略、保留策略和连续聚合刷新策略。在 Timescale 上，此表有一个触发器，确保任何数据库用户都无法创建或修改其他数据库用户拥有的作业。此触发器可能会对迁移造成障碍。

如果 `pg_dump` 和 `pg_restore` 使用 `--no-owner` 标志，目标数据库中的所有对象都将由运行 `pg_restore` 的用户（很可能是 `tsdbadmin`）拥有。

如果源数据库中的所有后台作业都由与运行恢复的用户同名的用户（很可能是 `tsdbadmin`）拥有，那么加载 `_timescaledb_config.bgw_jobs` 表应该会成功。

如果源中的后台作业由 `postgres` 用户拥有，它们将自动更改为由 `tsdbadmin` 用户拥有。在这种情况下，只需验证这些作业没有使用 `tsdbadmin` 用户不具备的权限即可。

如果后台作业由恢复过程中使用的用户以外的一个或多个用户拥有，则可能会出现问题。为了解决此问题，请勿使用 `pg_dump` 转储此表。向 `pg_dump` 提供 `--exclude-table-data='_timescaledb_config.bgw_job'` 或 `--exclude-table='_timescaledb_config.bgw_job'` 以跳过此表。然后，使用 `psql` 和 `COPY` 命令转储并恢复此表，并修改 `owner` 列的值。

# dump the _timescaledb_config.bgw_job table to a csv file replacing the owner 
# values with tsdbadmin
psql -d "$SOURCE" -X -v ON_ERROR_STOP=1 --echo-errors -f - <<'EOF'
begin;
select string_agg
( case attname
    when 'owner' then $$'tsdbadmin' as "owner"$$
    else format('%I', attname)
  end
, ', '
) as cols
from pg_namespace n
inner join pg_class c
on (n.nspname = '_timescaledb_config'
and n.oid = c.relnamespace
and c.relname = 'bgw_job')
inner join pg_attribute a
on (c.oid = a.attrelid and a.attnum > 0)
\gset
copy
(
    select :cols 
    from _timescaledb_config.bgw_job
    where id >= 1000
) to stdout with (format csv, header true)
\g bgw_job.csv
rollback;
\q
EOF

# copy the csv file into the target's _timescaledb_config.bgw_job
psql -X -d "$TARGET" -v ON_ERROR_STOP=1 --echo-errors \
    -c "\copy _timescaledb_config.bgw_job from 'bgw_job.csv' with (format csv, header match)"

复制

表加载并恢复完成后，您可以根据需要使用 SQL 调整作业的所有权和/或相关的存储过程和函数。

PostgreSQL 有大量可用的扩展。Timescale 支持许多最流行的扩展，但并非所有扩展。在迁移之前，请检查您正在使用的扩展是否在 Timescale 上受支持。请查阅支持的扩展列表。

自托管时，timescaledb 扩展可以安装在任意架构中。Timescale 仅支持在 `public` 架构中安装 timescaledb 扩展。如何解决此问题在很大程度上取决于源架构的具体细节和所选择的迁移方法。

Timescale 不支持使用自定义表空间。在转储/恢复架构时向 `pg_dump` 和 `pg_restore` 提供 `--no-tablespaces` 标志会使所有对象都位于默认表空间中，从而达到预期效果。

虽然 PostgreSQL 集群可以包含许多数据库，但 Timescale 实例仅限于单个数据库。将包含多个数据库的集群迁移到 Timescale 时，可以将每个源数据库迁移到单独的 Timescale 实例，或将源数据库“合并”到目标架构。

tsdbadmin 数据库用户是 Timescale 上可用的最强大的用户，但它并非真正的超级用户。在迁移之前，请检查您的应用程序是否使用了超级用户特权操作并进行相应的缓解。

为了提高连续聚合的性能和兼容性，TimescaleDB v2.7 将*部分*连续聚合替换为*最终化*连续聚合。

要测试您的数据库中是否存在部分连续聚合，请运行以下查询

SELECT exists (SELECT 1 FROM timescaledb_information.continuous_aggregates WHERE NOT finalized);

复制

如果您的数据库中存在部分连续聚合，请在迁移数据库之前将它们从部分聚合迁移到最终化聚合。

如果您不小心在 PostgreSQL 版本之间迁移了部分连续聚合，在查询任何连续聚合时，您会看到以下错误

ERROR:  insufficient data left in message.

复制