citus多CN部署

在citus中一般使用一个CN节点多个work节点的模式，但是这种模式往往会面临一个问题：cn节点产生性能瓶颈。所以这种情况我们部署多cn还是很有必要的。
如果CN上主要的负载来自查询，可以为CN节点配置多个备机，做读写分离，这些备机可以分担读负载。但是这种方案不能称为多CN，它不具有均衡写负载的能力。
那么该怎么实现多CN呢？这里我们要介绍下citus中的MX模式，MX模式是citus的扩展，允许app直接连接work节点进行数据的读取和写入并增加集群的并发数量。而之所以MX能实现这一功能，就是因为CN节点和work节点的区别就在于是否存储了相关的元数据，当work节点拥有这些元信息后，便可以提供数据的读取和写入服务。

MX模式有以下限制：
1、MX模式不允许执行DDL操作，所有DDL的操作需要通过协调器节点进行，换句话说就是只运行分布式表的DML操作和select操作。
2、fdw不支持，包括cstore
3、必须使用bigserial序列（其他博客Citus序列实现查看详细）。

配置方法：

SET citus.replication_model TO ‘streaming’;
SELECT start_metadata_sync_to_node(‘localhost’, port);

例子：
查看当前citus集群信息：

citus=# select * from pg_dist_node;
 nodeid | groupid | nodename | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster | metadatasynced 
--------+---------+----------+----------+----------+-------------+----------+----------+-------------+----------------
      2 |       2 | oracle   |     2019 | default  | f           | t        | primary  | default     | f
      6 |       6 | dmdb04   |     1921 | default  | f           | t        | primary  | default     | f
(2 rows)

从CN复制元数据到groupid=6的节点：

citus=# set citus.replication_model='streaming';
SET
citus=# SELECT start_metadata_sync_to_node('dmdb04', 1921);
 start_metadata_sync_to_node 
-----------------------------
 
(1 row)

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

citus=# select * from pg_dist_node;
 nodeid | groupid | nodename | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster | metadatasynced 
--------+---------+----------+----------+----------+-------------+----------+----------+-------------+----------------
      2 |       2 | oracle   |     2019 | default  | f           | t        | primary  | default     | f
      6 |       6 | dmdb04   |     1921 | default  | t           | t        | primary  | default     | t
(2 rows)

验证测试：
cn节点创建分片表：

citus=# create table tb1(id int primary key, c1 int);
CREATE TABLE
citus=# set citus.shard_count=8;
SET
citus=# select create_distributed_table('tb1','id');
 create_distributed_table 
--------------------------
 
(1 row)

去扩展work节点执行：
可以看到这个SQL可以在dmdb04这个work节点上执行。

citus=# explain select * from tb1;
                                  QUERY PLAN                                  
------------------------------------------------------------------------------
 Custom Scan (Citus Adaptive)  (cost=0.00..0.00 rows=0 width=0)
   Task Count: 8
   Tasks Shown: One of 8
   ->  Task
         Node: host=dmdb04 port=1921 dbname=citus
         ->  Seq Scan on tb1_102049 tb1  (cost=0.00..32.60 rows=2260 width=8)
(6 rows)

多CN模式优化：
这种扩展work的模式有一个很大的弊端，cn节点和work节点混合在同一个节点上，这会带来很多问题：
1、扩展Worker上的负载可能不均衡；
2、如果出现性能问题增加了故障排查的难度；
3、CN和Worker将不能独立扩容；
4、扩大了插件兼容问题的影响。
为了解决该问题，我们可以使用几个work节点来单独作为CN的角色，而不在当作work来使用。具体的方法大致为：将分片到扩展work节点上的手动移走到其它work节点上。