Citus分布式方案(七)- 集群管理

本文详细介绍Citus数据库集群的管理策略,包括集群大小选择、硬件配置、节点扩容与故障处理,以及如何通过企业版特性实现租户隔离和资源合理利用。同时,介绍了如何查看统计信息,以优化查询执行。

(七)集群管理

在本节内容:从Citus集群中添加或删除节点,以及如何处理节点故障。

选择集群的大小

为了更容易跨节点移动分片或在失败节点上重新复制分片,Citus企业版提供了一个分片重均衡的扩展。在此之前,我们将了解下在生产环境中运行集群的配置。

1. 分片的数量

集群中的节点数量很容易更改,但是在集群创建之后,更改在这些节点之间分布的分片数量就变得复杂了。为每个分布式表选择分片初始数量需要在更多分片的灵活性与跨分片查询的开销之间的做好平衡。

2. 多租户SaaS

在多租户数据库用例中,官方建议在32 - 128个碎片之间进行选择。对于较小的工作负载(比如<100GB),可以从32个碎片开始,对于较大的工作负载,可以选择64或128,但这意味着需要将数据节点的数量从32台扩展到128台。

3. 实时分析

在实时分析用例中,分片数量应该与工作程序上核心的总数有关。 为了确保最大的并行度,应该在每个节点上创建足够的分片,以使每个CPU内核至少有一个分片。 我们通常建议创建大量初始分片,如当前CPU内核数量的2倍或4倍,以便在将来进行扩展。

不过,对于每个查询,Citus会为每个分片打开一个数据库连接,并且这些连接受到连接总数的限制。注意分片数量不能过大,以避免带来分布式查询不必的连接等待。 换句话说,所需的连接(最大并发查询数×分片数)通常不应超过系统中可能的总连接数(数据节点数×每个数据节点的max_connections)。

初始硬件大小

集群的大小,就节点数及其硬件容量而言,很容易更改。但是,仍然需要为新集群选择初始大小。

1. 多租户SaaS

对于从现有的单节点数据库实例迁移到Citus的用户,建议选择一个群集,其中数据节点的核心和RAM的总数等于原始实例的数目。由于分片提高了资源利用率,允许使用更小的索引,因此很容易得到2-3倍的性能提升。

协调节点比数据节点需要更少的内存,因此可以选择偏重于CPU的计算机来运行协调节点。 所需的内核数量取决于现有的工作负载(读/写吞吐量)。

2. 实时分析

核心总数:Citus的性能提升与工作核心数成正比。确定适合的核心数量,需要考虑单节点数据库中当前查询的延迟以及Citus中所需的延迟,可以使用当前等待时间除以所需等待时间四舍五入后的结果。

数据节点RAM:最好的情况是提供足够的内存,使大部分工作集都能存放在内存中。应用程序使用的查询类型会影响内存需求,通过对查询运行EXPLAIN (ANALYZE, BUFFERS)以确定它需要多少内存。

集群扩容

Citus的基于逻辑分片的体系结构可以扩展集群而无需停机。

1. 添加一个数据节点

Citus将所有数据存储在数据节点上的分布式表中,因此,如果通过增加更多的计算能力来扩展集群,可以通过增加一个数据节点来实现。

要将新节点添加到集群,首先需要在pg_dist_node目录表中添加该节点和端口(运行PostgreSQL的端口),包括DNS名称或IP地址,可以使用master_add_node()函数执行:

SELECT * from master_add_node('node-name', 5432);

新节点可用于新的分布式表的分片。如果不进行重新分配,那么现有分片将保留在原处,因此,如果不采取进一步措施,添加新的数据节点可能对性能没有任何帮助。

如果群集里有非常大的参考表,那它们可能会减慢节点的添加速度。在这种情况下,可以考虑设置citus.replicate_reference_tables_on_activate(boolean)延迟引用表复制。

从Citus 8.1开始,数据节点默认使用加密通信。运行8.1或更高版本的新节点将拒绝与未启用SSL的其他数据节点通信,因此,将节点添加到没有加密通信的群集中时,必须在创建Citus扩展之前重新配置新节点。

首先,从协调节点检查其他工作人员是否使用SSL:

SELECT run_command_on_workers('show ssl');

如果没有,那么连接到新节点,并允许它在必要时通过明文通信:

ALTER SYSTEM SET citus.node_conninfo TO 'sslmode=prefer';
SELECT pg_reload_conf();

2. 在不停机的情况下重新平衡分片

如果要将现有的分片移动到新添加的工作器中,Citus企业版提供了rebalance_table_shards()函数来简化此工作。此功能将移动给定表的分片以在数据节点之间平均分配它们。

该功能可配置为根据多种策略重新平衡分片,示例使用默认策略重新分配分片:

SELECT rebalance_table_shards();

许多用户场景,例如多租户SaaS应用程序,都无法忍受停机时间,Citus(PostgreSQL 10及以上版本)重新平衡功能可以满足这一要求。在移动数据时,Citus能够以最小的中断来执行应用程序的读取和写入。

3. 工作原理

Citus的分片重新平衡使用PostgreSQL逻辑复制将数据从旧分片(在复制方面称为发布方)移动到新分片(订阅方)。逻辑复制允许应用程序读写在复制分片数据时可以连续不间断地进行。Citus仅在更新元数据以将订阅方分片提升为活动状态时才对分片进行简短的写锁定。

如果分布式表已定义了主键,则无需进行任何额外的工作即可进行分片重新平衡。但是,如果它没有主键或没有明确定义的副本标识,则尝试重新平衡它会导致错误。例如:

-- creating the following table without REPLICA IDENTITY or PRIMARY KEY
CREATE TABLE test_table (key int not null, value text not null);
SELECT create_distributed_table('test_table', 'key');

-- running shard rebalancer with default behavior
SELECT rebalance_table_shards('test_table');

/*
NOTICE:  Moving shard 102040 from localhost:9701 to localhost:9700 ...
ERROR: cannot use logical replication to transfer shards of the
  relation test_table since it doesn't have a REPL
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值