警告

多节点支持已弃用.

TimescaleDB v2.13 是最后一个为 PostgreSQL 版本 13、14 和 15 提供多节点支持的版本。

通过为集群中的每个节点设置一个或多个备用节点，或者通过在数据块级别本地复制数据，可以使 TimescaleDB 的多节点安装实现高可用性。

使用备用节点依赖于流复制，其设置方式与配置单节点 HA类似，尽管配置需要独立应用于每个节点。

要在数据块级别复制数据，您可以使用多节点 TimescaleDB 的内置功能，避免必须复制整个数据节点。访问节点仍然依赖于流复制备用节点，但数据节点不需要额外的配置。相反，现有的数据节点池共同承担托管数据块副本和处理节点故障的责任。

每种方法都有其优点和缺点。为集群中的每个节点设置备用节点可确保备用节点在实例级别上是相同的，这是一种经过验证的提供高可用性的方法。但是，它也需要为镜像集群进行更多的设置和维护。

本地复制通常需要更少的资源、节点和配置，并利用内置功能，例如添加和删除数据节点，以及每个分布式超表上不同的复制因子。但是，只有数据块会在数据节点上复制。

本节的其余部分讨论本地复制。要为每个节点设置备用节点，请按照单节点 HA的说明进行操作。

本地复制是一组功能和 API，允许您构建高可用性的多节点 TimescaleDB 安装。本地复制的核心是将数据块的副本写入多个数据节点，以便在数据节点发生故障时拥有备用的数据块副本。如果一个数据节点发生故障，其数据块应在至少一个其他数据节点上可用。如果一个数据节点永久丢失，则可以将新的数据节点添加到集群，并且可以从其他数据节点重新复制丢失的数据块副本，以达到所需的数据块副本数量。

警告

TimescaleDB 中的本地复制正在开发中，目前缺少完整高可用性解决方案的功能。本节中描述的某些功能仍处于实验阶段。对于生产环境，我们建议为多节点集群中的每个节点设置备用节点。

类似于单节点 PostgreSQL 的高可用性配置如何使用 Patroni 等系统来自动处理故障转移，本地复制需要外部实体来协调故障转移、数据块重新复制和数据节点管理。TimescaleDB 默认不提供此编排，因此需要单独实现。以下各节描述了如何在节点发生故障时启用本地复制以及实现高可用性的步骤。

启用本地复制的第一步是为访问节点配置备用节点。此过程与设置单节点备用节点相同。

下一步是在分布式超表上启用本地复制。本地复制由 replication_factor 管理，它决定一个数据块要复制到多少个数据节点。此设置是为每个超表单独配置的，这意味着同一个数据库可以有一些复制的分布式超表，而另一些则没有。

默认情况下，复制因子设置为 1，因此没有本地复制。您可以在创建超表时增加此数字。例如，要将数据复制到总共三个数据节点

SELECT create_distributed_hypertable('conditions', 'time', 'location',
 replication_factor => 3);

复制

或者，您可以使用set_replication_factor调用来更改现有分布式超表的复制因子。但是请注意，只有新的数据块才会根据更新后的复制因子进行复制。现有数据块需要通过将这些数据块复制到新的数据节点来重新复制（请参阅下面的节点故障部分）。

启用本地复制后，复制会在您每次向表中写入数据时发生。在每次 INSERT 和 COPY 调用时，数据的每一行都会写入多个数据节点。这意味着您无需执行任何额外的步骤即可复制新摄取的数据。当您查询复制的数据时，查询计划器仅在查询计划中包含每个数据块的一个副本。

当数据节点发生故障时，尝试写入故障节点的插入操作将导致错误。这是为了在数据节点再次可用时保持数据一致性。您可以使用alter_data_node调用，通过运行以下查询将故障数据节点标记为不可用

SELECT alter_data_node('data_node_2', available => false);

复制

将 available => false 设置为表示数据节点不再用于读取和写入查询。

为了故障转移读取，alter_data_node 调用会查找所有将不可用数据节点作为主要查询目标的数据块，并故障转移到另一个数据节点上的数据块副本。但是，如果某些数据块没有可故障转移到的副本，则会发出警告。对于在任何其他数据节点上都没有数据块副本的数据块，读取操作将继续失败。

为了故障转移写入，任何旨在写入故障节点的活动都会将涉及的数据块标记为针对特定故障节点过时，方法是更改访问节点上的元数据。这仅针对本地复制的数据块完成。这允许您在故障节点被标记为不可用时继续写入其他数据节点上的其他数据块副本。对于在任何其他数据节点上都没有数据块副本的数据块，写入操作将继续失败。另请注意，故障节点上未写入的数据块不受影响。

当您将数据块标记为过时时，该数据块将变得复制不足。当故障数据节点变得可用时，可以使用copy_chunk API 重新平衡此类数据块。

如果等待数据节点恢复不是一个选项，要么是因为时间太长，要么是因为节点永久故障，则可以删除它。要能够删除数据节点，其所有数据块必须在其他数据节点上至少有一个副本。例如

SELECT delete_data_node('data_node_2', force => true);
WARNING:  distributed hypertable "conditions" is under-replicated

复制

如果删除数据节点意味着集群不再达到所需的复制因子，请在删除数据节点时使用 force 选项。除非数据节点没有数据块，或者分布式超表的数据块副本多于配置的复制因子，否则这将是正常情况。

重要提示

如果删除数据节点意味着多节点集群永久丢失数据，则您无法强制删除该数据节点。

当您成功删除故障数据节点或将故障数据节点标记为不可用时，某些数据块可能缺少副本，但查询和插入操作会再次正常工作。但是，在所有数据块都完全复制之前，集群仍处于脆弱状态。

当您恢复故障数据节点或再次将其标记为可用时，您可以使用以下查询查看需要复制的数据块

SELECT chunk_schema, chunk_name, replica_nodes, non_replica_nodes
FROM timescaledb_experimental.chunk_replication_status
WHERE hypertable_name = 'conditions' AND num_replicas < desired_num_replicas;

复制

此查询的输出如下所示

chunk_schema      |      chunk_name       | replica_nodes |     non_replica_nodes
-----------------------+-----------------------+---------------+---------------------------
 _timescaledb_internal | _dist_hyper_1_1_chunk | {data_node_3} | {data_node_1,data_node_2}
 _timescaledb_internal | _dist_hyper_1_3_chunk | {data_node_1} | {data_node_2,data_node_3}
 _timescaledb_internal | _dist_hyper_1_4_chunk | {data_node_3} | {data_node_1,data_node_2}
(3 rows)

复制

通过数据块复制状态视图中的信息，可以将复制不足的数据块复制到新节点，以确保该数据块具有足够数量的副本。例如

CALL timescaledb_experimental.copy_chunk('_timescaledb_internal._dist_hyper_1_1_chunk', 'data_node_3', 'data_node_2');

复制

重要提示

当您恢复数据块复制时，该操作使用多个事务。这意味着它无法自动回滚。如果您在操作完成之前取消操作，则会记录复制操作的操作 ID。您可以使用此操作 ID 清理取消操作留下的任何状态。例如

CALL timescaledb_experimental.cleanup_copy_chunk_operation('ts_copy_1_31');

复制