故障排除

ERROR: permission denied for schema _timescaledb_internal

当使用 ALTER TABLE 命令更改表或超表的所有权时，您可能会看到此错误。

阻止使用 ALTER TABLE 是因为 tsdbadmin 用户不是超级用户。

要更改表所有权，请改用 REASSIGN 命令

REASSIGN OWNED BY <current_role> TO <desired_role>

复制

ERROR:  could not create unique index
DETAIL:  Table contains duplicated values.

当您尝试使用 REINDEX 重建索引时，由于冲突的重复行而失败。

要识别冲突的重复行，您需要运行一个查询，该查询计算索引定义中包含的每列组合的行数。

例如，此 route 表有一个 unique_route_index 索引，该索引基于 source 和 destination 列的组合定义唯一行

CREATE TABLE route(
    source TEXT,
    destination TEXT,
    description TEXT
    );

CREATE UNIQUE INDEX unique_route_index
    ON route (source, destination);

复制

如果 unique_route_index 已损坏，您可以使用此查询在 route 表中查找重复的行

SELECT
    source,
    destination,
    count
FROM
    (SELECT
        source,
        destination,
        COUNT(*) AS count
    FROM route
    GROUP BY
        source,
        destination) AS foo
WHERE count > 1;

复制

该查询按索引中定义的相同 source 和 destination 字段对数据进行分组，并过滤掉出现多次的任何条目。

通过手动删除或合并条目来解决行中的问题条目，直到不存在重复项。 删除所有重复条目后，您可以使用 REINDEX 命令重建索引。

这发生在我们所有人身上，您想登录 MST 控制台，但密码在您的钥匙旁边，无论它们在哪里。

重置密码

1. 打开 MST 门户。
2. 点击 “忘记密码”。
3. 输入您的电子邮件地址，然后点击 “重置密码”。

安全的重置密码链接已发送到与此帐户关联的电子邮件。 点击链接并更新您的密码。

Your Managed Service for TimescaleDB service, in project "ExampleAccount", is running low on
CPU. Running low on CPU affects performance and could affect service
availability. Please either optimize your usage pattern or reduce the workload,
and consider upgrading to a larger plan to avoid service outage.

当您的数据库达到您分配的磁盘、内存或 CPU 资源的 90% 时，将向您的电子邮件地址发送一条包含上述文本的自动消息。

您可以通过登录您的 Managed Service for TimescaleDB 帐户并增加可用资源来解决此问题。 从 Managed Service for TimescaleDB 仪表板中，选择您要增加资源的的服务。 在 “概览” 选项卡中，找到 “服务计划” 部分，然后单击 “升级计划”。 选择适合您需求的计划，然后单击 “升级” 以启用其他资源。

如果您经常耗尽资源，您可能需要考虑更有效地使用您的资源。 考虑启用 压缩、使用 连续聚合 或 配置数据保留 以减少数据库使用的资源量。

Managed Service for TimescaleDB 服务需要 DNS 记录。 当您启动新服务时，会创建 DNS 记录，新名称可能需要一些时间才能传播到世界各地的 DNS 服务器。

如果您将现有服务移动到新的云提供商或区域，则服务会在后台在新区域中重建。 当服务已在新区域中重建后，DNS 记录将更新。 这可能会在 DNS 更改传播时导致您的服务短暂中断。

如果您无法解析 DNS，请等待几分钟然后重试。

PostgreSQL 中的事务控制机制为数据库中修改的每一行分配一个事务 ID； 这些 ID 控制该行对其他并发事务的可见性。 事务 ID 是一个 32 位数字，其中 20 亿个 ID 始终在可见的过去，其余 ID 保留供将来事务使用，并且对正在运行的事务不可见。 为避免旧行的事务回绕，PostgreSQL 需要偶尔清理和冻结旧行。 这确保在创建更多事务时现有行是可见的。 您可以通过执行 VACUUM FREEZE 手动冻结旧行。 当自上次冻结点以来已创建配置数量的事务时，也可以使用 autovacuum 守护程序自动完成此操作。

在 Managed Service for TimescaleDB 中，事务限制根据数据库的大小设置，最多 15 亿个事务。 这确保在强制冻结之前有 5 亿个事务 ID 可用，并避免搅动现有表中的稳定数据。 要检查您的事务冻结限制，您可以在 PostgreSQL 实例中执行 show autovacuum_freeze_max_age。 达到限制后，autovacuum 开始冻结旧行。 某些应用程序在 PostgreSQL 设置更改时不会自动调整配置，这可能会导致不必要的警告。 例如，PGHero 的默认设置会在创建 5 亿个事务时发出警报，而不是在 15 亿个事务后发出警报。 为避免这种情况，请将 transaction_id_danger 设置的值从 1,500,000,000 更改为 500,000,000，以便在事务限制达到 15 亿时收到警告。