故障排除

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 Console，但密码就像您的钥匙一样，不知放在何处。

要重置您的密码

1. 打开 MST 门户。
2. 点击 Forgot password。
3. 输入您的电子邮件地址，然后点击 Reset password。

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

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 控制面板中，选择要增加资源的服务。在“概览”选项卡中，找到“服务计划”部分，然后点击“升级计划”。选择适合您需求的计划，然后点击“升级”以启用额外资源。

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

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

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

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

PostgreSQL 中的事务控制机制为数据库中修改的每一行分配一个事务 ID；这些 ID 控制该行对其他并发事务的可见性。事务 ID 是一个 32 位数字，其中二十亿个 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 亿时收到警告。