citus实战系列之四多CN部署-阿里云开发者社区

开发者社区> 数据库> 正文

citus实战系列之四多CN部署

简介: citus的架构中正常只有1个CN节点,有时候CN会成为性能瓶颈。我们可以通过减少分片数,垂直扩容CN节点等手段缓解CN的性能问题,但这些都不能治本。某些业务场景部署多个CN节点是非常必要的。

citus实战系列之四多CN部署

背景

citus的架构中正常只有1个CN节点,有时候CN会成为性能瓶颈。我们可以通过减少分片数,垂直扩容CN节点等手段缓解CN的性能问题,但这些都不能治本。某些业务场景部署多个CN节点是非常必要的。

技术方案

如果CN上主要的负载来自查询,可以为CN节点配置多个备机,做读写分离,这些备机可以分担读负载。但是这种方案不能称为多CN,它不具有均衡写负载的能力。

怎么实现多CN呢?在citus的具体实现中,CN和worker的区别就在于是否存储了相关的元数据,如果把CN的元数据拷贝一份到worker上,那么worker也可以向CN一样工作,这个多CN的模式早期被称做masterless。

对于当前的citus版本,其实有一个开关,打开后,会自动拷贝CN的元数据到Worker上,让worker也可以当CN用。 这个功能官方被称做Citus MX,也就是下一代的Citus,目前仅在Cloud Beta版中使用。好消息是,社区版虽然没有公开说支持,但也没有从代码上限制这个功能。下面见证一下这个神奇的开关:)

在CN节点的postgresql.conf中添加下面的参数

citus.replication_model='streaming'

在CN节点(cituscn)上添加worker节点

SELECT * from master_add_node('cituswk1', 5432);
SELECT * from master_add_node('cituswk2', 5432);

从CN复制元数据到第一个worker节点

SELECT start_metadata_sync_to_node('cituswk1', 5432);

执行上面的函数后,citus CN上的元数据会被拷贝到指定的worker上,并且pg_dist_node表中对应worker的hasmetadata字段值为true,标识这个Worker存储了元数据,以后创建新的分片时,新产生的元素据也会自动同步到这个worker上。

postgres=# select * from pg_dist_node;
 nodeid | groupid | nodename | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster 
--------+---------+----------+----------+----------+-------------+----------+----------+-------------
      1 |       1 | cituswk1 |     5432 | default  | t           | t        | primary  | default
      2 |       2 | cituswk2 |     5432 | default  | f           | t        | primary  | default
(2 rows)

下面看一下效果

在CN节点上创建一个测试分片表

create table tb1(id int primary key, c1 int);
set citus.shard_count=8;
select create_distributed_table('tb1','id');
insert into tb1 select id,random()*1000 from generate_series(1,100)id;

因为cituswk1带了元数据,可以当CN用,下面这个SQL可以在cituswk1上执行。

postgres=# explain select * from tb1;
                                  QUERY PLAN                                  
------------------------------------------------------------------------------
 Custom Scan (Citus Real-Time)  (cost=0.00..0.00 rows=0 width=0)
   Task Count: 8
   Tasks Shown: One of 8
   ->  Task
         Node: host=cituswk1 port=5432 dbname=postgres
         ->  Seq Scan on tb1_102092 tb1  (cost=0.00..32.60 rows=2260 width=8)
(6 rows)

为了说明方便,后面把这种带了元数据的worker称之为“扩展worker”。citus会限制某些SQL在扩展worker上执行,比如DDL。

分片位置的控制

扩展Worker其实把Worker和CN两个角色混在一个节点里,对维护不是很友好。有下面几个表现:

  1. 扩展Worker上的负载可能不均衡
  2. 如果出现性能问题增加了故障排查的难度
  3. CN和Worker将不能独立扩容
  4. 扩大了插件兼容问题的影响
    一个例子是,当前citus的CN节点和auto_explain插件是冲突的,但Worker和auto_explain相安无视。一旦所有worker都作为扩展worker,那么所有的worker也都不能幸免。auto_explain插件只是我们在实际部署时遇到的一个例子,其它插件可能会有类似情况。

为解决这些问题,我们可以专门定义少数几个节点作为扩展Worker,并且不在上面分配分片,使其纯粹担任CN的角色。具体作法如下:

首先,按通常的方式建好分片表,再使用前面《citus实战系列之三平滑扩容》中介绍的方法把"扩展Worker"上的分片挪走。

对于前面tb1的例子,有4个分片落在扩展worker(worker1)上

postgres=# select * from pg_dist_shard_placement where nodename='cituswk1';
 shardid | shardstate | shardlength | nodename | nodeport | placementid 
---------+------------+-------------+----------+----------+-------------
  102238 |          1 |           0 | cituswk1 |     5432 |         237
  102240 |          1 |           0 | cituswk1 |     5432 |         239
  102242 |          1 |           0 | cituswk1 |     5432 |         241
  102244 |          1 |           0 | cituswk1 |     5432 |         243
(4 rows)

创建分片表

create table tba(id int);
set citus.shard_count=8;
select create_distributed_table('tba','id');

此时,有6个分片落在"扩展Worker"上。

postgres=# select * from pg_dist_shard_placement where nodename='cituswk1';
 shardid | shardstate | shardlength |  nodename  | nodeport | placementid 
---------+------------+-------------+------------+----------+-------------
  103081 |          1 |           0 |  cituswk1  |     5432 |        1096
  103083 |          1 |           0 |  cituswk1  |     5432 |        1099
  103085 |          1 |           0 |  cituswk1  |     5432 |        1102
  103097 |          1 |           0 |  cituswk1  |     5432 |        1105
(4 rows)

把"扩展Worker"上的分片挪走。

select citus_move_shard_placement(102238,'cituswk1',5432,'cituswk2',5432,'drop');
select citus_move_shard_placement(102240,'cituswk1',5432,'cituswk2',5432,'drop');
select citus_move_shard_placement(102242,'cituswk1',5432,'cituswk2',5432,'drop');
select citus_move_shard_placement(102244,'cituswk1',5432,'cituswk2',5432,'drop');

这是CN的元数据已经更新了,但扩展Worker(worker1)还没有,需要在扩展Worker(worker1)上更新分片位置

postgres=# update pg_dist_shard_placement set nodename='cituswk2' where shardid in (102238,102240,102242,102244);
UPDATE 4

先定义后迁移的方式不是特别方便,对于有亲和关系(分片位置分布完全一致)的表,只有第一张表需要这样定义,后续的表可以利用亲和关系指定分片的部署位置。

比如

create table tb2(id int);
select create_distributed_table('tb2','id', colocate_with=>'tb1');

上面的colocate_with有3种取值

  • default: 分配数,副本数,分片字段类型相同的表自动分配到一个亲和组
  • none:开始一个新的亲和组
  • 表名:希望与之亲和的另一个表的表名

注意事项

稳妥起见,在扩展worker上尽量避免会产生分布式事务或死锁的操作。建议只执行这几类SQL,并且不使用事务。

  • SELECT
  • INSERT
  • 条件中带分片字段的SQL

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章