常见问题解答和故障排除

在线迁移工具目前处于实验阶段。您可能会遇到以下缺点

• 在线迁移尚不支持可变压缩（在压缩数据上进行 INSERT、UPDATE、DELETE 操作）。
• 默认情况下，包含 NaN/+Inf/-Inf 值的数字字段不会被正确复制，并将转换为 NULL。虽然有可用的解决方法，但默认情况下未启用。

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

您可以直接从 Timescale 控制台提交支持请求，或通过电子邮件发送至 support@timescale.com。

在线迁移涉及多个后台进程来管理迁移的不同阶段。这些进程的日志对于排除意外行为非常有用。您可以在 <volume_mount>/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 之前）
• 使用外键创建超表，截断超表
• 在超表上启用压缩
• 删除块

上述情况最可能的影响是，保留策略、压缩策略和连续聚合刷新策略的后台作业在 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 转储此表。提供 --exclude-table-data='_timescaledb_config.bgw_job' 或 --exclude-table='_timescaledb_config.bgw_job' 给 pg_dump 以跳过此表。然后，使用 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 仅支持将 timescaledb 扩展安装在 public 模式中。如何解决此问题在很大程度上取决于源模式的具体细节和选择的迁移方法。

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.

复制