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两个角色混在一个节点里，对维护不是很友好。有下面几个表现：
- 扩展Worker上的负载可能不均衡
- 如果出现性能问题增加了故障排查的难度
- CN和Worker将不能独立扩容
- 扩大了插件兼容问题的影响
一个例子是，当前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
