警告

多节点支持已停止.

TimescaleDB v2.13 是最后一个包含对 PostgreSQL 13、14 和 15 版本多节点支持的版本。

多节点 TimescaleDB 允许您直接从访问节点管理集群。当您的环境设置完成后，您无需直接登录到数据节点即可管理数据库。

当您执行管理任务时，例如添加新列、更改权限或在分布式超表上添加索引，您可以从访问节点执行该任务，并且它将应用于所有数据节点。但是，如果命令在常规表上执行，则该命令的效果仅在访问节点本地应用。同样，如果命令直接在数据节点上执行，则结果仅在该数据节点上可见。

在分布式数据库中创建或修改模式、角色、表空间和设置的命令也不会自动分发。这是因为这些对象和设置有时需要在访问节点上与数据节点不同，甚至在数据节点之间也可能有所不同。例如，数据节点可能具有独特的 CPU、内存和磁盘配置。节点差异使得无法假设单一配置适用于所有节点。此外，与数据节点相比，公共可访问的访问节点上的一些设置需要不同，例如具有不同的连接限制。角色在访问节点上可能没有 `LOGIN` 权限，但它需要在数据节点上具有此权限，以便访问节点可以连接。

角色和表空间还在同一实例的多个数据库之间共享。其中一些数据库可能是分布式的，而另一些可能不是，或者配置了不同的数据节点集。因此，鉴于这些命令可以在不需要分布式的不同数据库中执行，因此无法确定何时应将角色或表空间分发到数据节点。

要从访问节点管理多节点集群，您可以使用 distributed_exec 函数。此函数允许完全控制在所有数据节点上创建和配置数据库设置、模式、角色和表空间。

本节的其余部分更详细地描述了在多节点环境中如何处理特定的管理任务。

在多节点环境中，您需要独立管理每个 PostgreSQL 实例上的角色，因为角色是实例级别的对象，它们在分布式和非分布式数据库之间共享，每个数据库都可以配置不同的数据节点集或根本没有。因此，访问节点不会自动在其数据节点之间分发角色或角色管理命令。当数据节点添加到集群时，假定它已经具有与其余节点一致所需的适当角色。如果不是这种情况，当您尝试创建或更改依赖于缺少或设置不正确的角色的对象时，您可能会遇到意外错误。

为了帮助从访问节点管理角色，您可以使用 distributed_exec 函数。这对于在当前数据库的所有数据节点上创建和配置角色非常有用。

当您创建分布式角色时，重要的是要考虑同一个角色在访问节点上可能需要与数据节点不同的配置。例如，用户可能需要密码才能连接到访问节点，而集群内部节点之间则使用证书认证。您可能还希望对外部连接设置连接限制，但允许无限制地内部连接到数据节点。例如，以下用户可以使用密码向访问节点建立 10 个连接，但在连接到数据节点时没有限制

CREATE ROLE alice WITH LOGIN PASSWORD 'mypassword' CONNECTION LIMIT 10;
CALL distributed_exec($$ CREATE ROLE alice WITH LOGIN CONNECTION LIMIT -1; $$);

复制

有关设置认证的更多信息，请参阅多节点认证部分。

某些角色也可以在访问节点上不配置 `LOGIN` 属性。这允许您在本地切换到该角色，但不能从远程位置以该用户身份连接。但是，要能够以该用户身份从访问节点连接到数据节点，数据节点需要将该角色配置为启用 `LOGIN` 属性。要在多节点设置中创建非登录角色，请使用以下命令

CREATE ROLE alice WITHOUT LOGIN;
CALL distributed_exec($$ CREATE ROLE alice WITH LOGIN; $$);

复制

要允许新角色创建分布式超表，还需要授予它在数据节点上的使用权限，例如

GRANT USAGE ON FOREIGN SERVER dn1,dn2,dn3 TO alice;

复制

通过授予某些数据节点而非其他数据节点的使用权限，您可以根据角色将使用限制在数据节点的子集上。

当您更改分布式角色时，请使用与创建角色相同的过程。需要分两个单独的步骤在访问节点和数据节点上更改角色。例如，按如下方式向角色添加 `CREATEROLE` 属性

ALTER ROLE alice CREATEROLE;
CALL distributed_exec($$ ALTER ROLE alice CREATEROLE; $$);

复制

分布式数据库可以包含分布式和非分布式对象。通常，当发出命令更改分布式对象时，它将应用于所有拥有该对象（或其一部分）的节点。

然而，在某些情况下，设置 *应该* 因节点而异，因为节点可能以不同的方式配置（例如，具有不同级别的 CPU、内存和磁盘能力），并且访问节点的作用与数据节点不同。

本节详细描述了当在分布式数据库中执行时，分布式对象上的命令如何以及何时应用于所有数据节点。

ALTER DATABASE 命令仅在访问节点本地应用。这是因为数据库级别的配置通常需要在不同节点之间有所不同。例如，这是一个可能根据节点的 CPU 能力而异的设置

ALTER DATABASE mydatabase SET max_parallel_workers TO 12;

复制

数据库名称在节点之间也可能不同，即使这些数据库是同一分布式数据库的一部分。当您重命名数据节点的数据库时，请务必更新访问节点上数据节点的配置，使其引用新的数据库名称。

当您在访问节点上删除分布式数据库时，它不会自动删除数据节点上对应的数据库。在这种情况下，您需要直接连接到每个数据节点并本地删除数据库。

分布式数据库不会自动在所有节点上删除，因为有关数据节点的信息存在于访问节点上的分布式数据库中，但在执行删除命令时无法读取它，因为连接到数据库时无法发出该命令。

此外，如果数据节点已永久失败，即使一个或多个数据节点没有响应，您也需要能够删除数据库。

如果可能，最好将数据保留在数据节点上。例如，即使在访问节点上删除了数据库之后，您可能仍希望备份数据节点。

或者，您可以在访问节点上删除数据库之前，使用 `drop_database` 选项删除数据节点

SELECT * FROM delete_data_node('dn1', drop_database => true);

复制

当您创建、更改或删除模式时，命令不会自动应用于所有数据节点。但是，当创建分布式超表时，如果其所属模式在数据节点上不存在，则会创建该缺失的模式。

要在所有数据节点上手动创建模式，请使用此命令

CREATE SCHEMA newschema;
CALL distributed_exec($$ CREATE SCHEMA newschema $$);

复制

如果模式是使用特定授权创建的，那么在发出命令之前，授权角色也必须存在于数据节点上。更改现有模式所有者也适用相同的情况。

DROP OWNED 命令用于删除角色拥有的所有对象，并准备删除该角色。执行以下命令以准备在分布式数据库的所有数据节点上删除角色

DROP OWNED BY alice CASCADE;
CALL distributed_exec($$ DROP OWNED BY alice CASCADE $$);

复制

但是请注意，在执行这些命令后，该角色可能仍拥有其他数据库中的对象。

使用 GRANT 或 REVOKE 语句配置的权限在分布式超表上运行时将应用于所有数据节点。当授予其他对象的权限时，需要使用 distributed_exec 手动分发命令。

如果要将默认权限应用于所有数据节点，则需要使用 distributed_exec 手动修改它们。默认权限引用的角色和模式在执行命令之前需要存在于数据节点上。

假定新的数据节点已具有任何已更改的默认权限。默认权限不会自动追溯应用于新的数据节点。

节点可能配置了不同的磁盘，因此需要在每个节点上手动配置表空间。特别是，访问节点的存储配置可能与数据节点不同，因为它通常不存储大量数据。因此，无法假定多节点集群中所有节点都存在相同的表空间配置。