citus多副本模式-开启,功能验证和使用约束

citus是一款基于PostgreSQL的插件,通过citus可以将单机版的PostgreSQL集合在一起形成分布式PostgreSQL数据库。citus支持两种模式的数据高可用策略:

  • 流复制模式 本质是基于PostgreSQL原生的主从实现高可用,citus集群中的每一个PostgreSQL实例均包含一主一从(或多从)节点,通过PostgreSQL自身的高可用特性保证数据不丢失
  • 多副本模式 本质是将一份数据存储在多个不同的PostgreSQL节点上,保证数据可用性

本文简单研究citus多副本的用法,以及使用上的一些问题,包含以下几个步骤

  1. 部署验证环境
  2. 开启多副本模式,并进行简单验证
  3. 测试多副本模式与流复制模式的兼容性

部署验证环境

搭建1协调节点+2数据节点citus集群如下(配置过程不是本文重点,略过此步骤)

节点 角色
192.168.0.1 协调节点+数据节点
192.168.0.2 数据节点
192.168.0.3 数据节点

开启多副本模式

配置和建表

  1. 连接到citus协调节点,执行以下命令即可开启多副本模式
# 设置副本数量(仅当前session有效),如需持久化应使用PostgreSQL的alter system命令
# 默认值为1,即只有1份数据,无高可用机制
set citus.shard_replication_factor = 3;
  1. 建分布式表
create table repl3(a int primary key , b int , c int );
select create_distributed_table('repl3', 'a');

验证建好的表具有3副本

我们从两个方面验证建好的表有3副本特性

  1. 元数据

查询元数据可以看到,每个shardid放置到了三个位置

repl1=# select t1.logicalrelid,t1.shardid,count(1) from pg_dist_shard t1, pg_dist_placement t2 where t1.shardid = t2.shardid group by t1.logicalrelid,t1.shardid;
 logicalrelid | shardid | count
--------------+---------+-------
 repl3        |  102247 |     3
 repl3        |  102248 |     3
 repl3        |  102234 |     3
...
  1. 物理数据

先插入一条数据,确认落在哪个分片上

# 插入一条数据,可以看到落在 102245 这个shardid上
repl1=# insert into repl3(a, b, c) values (0,0,0) ;
INSERT 0 1
repl1=# explain select * from repl3 where a = 0;
                                               QUERY PLAN
---------------------------------------------------------------------------------------------------------
 Custom Scan (Citus Adaptive)  (cost=0.00..0.00 rows=0 width=0)
   Task Count: 1
   Tasks Shown: All
   ->  Task
         Node: host=192.168.0.1 port=15432 dbname=repl1
         ->  Index Scan using repl3_pkey_102245 on repl3_102245 repl3  (cost=0.15..3.17 rows=1 width=12)
               Index Cond: (a = 0)
(7 rows)

# 

查看sharid对应的物理节点,发现在groupid1,2,3的节点上均有一个副本

repl1=# select t1.*, t2.* from pg_dist_shard t1, pg_dist_placement t2 where t1.shardid = t2.shardid and t1.shardid = 102245;
 logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue | placementid | shardid | shardstate | shardlength | groupid
--------------+---------+--------------+---------------+---------------+-------------+---------+------------+-------------+---------
 repl3        |  102245 | t            | -402653184    | -268435457    |         456 |  102245 |          1 |           0 |       2
 repl3        |  102245 | t            | -402653184    | -268435457    |         457 |  102245 |          1 |           0 |       3
 repl3        |  102245 | t            | -402653184    | -268435457    |         458 |  102245 |          1 |           0 |       1
(3 rows)

查询三个数据节点上对应shardid的表,发现数据确实存有3份

repl1=# select run_command_on_workers('select a from repl3_102245');
 run_command_on_workers
-------------------------
 (192.168.0.1,15432,t,0)
 (192.168.0.2,15432,t,0)
 (192.168.0.3,15432,t,0)
(3 rows)

至此,功能验证完毕

测试与citus流复制模式的兼容性

实际生产上,单个协调节点是肯定存在性能瓶颈的,开源citus在流复制模式下,可以将分布式元数据从协调节点同步到数据节点。

开启流复制

# 可以看到,citus使用的是statement模式,该模式下不支持将元数据同步到数据节点
repl1=# show citus.replication_model;
 citus.replication_model
-------------------------
 statement

# 这个配置对整个节点生效
alter system set citus.replication_model='streaming';
SELECT pg_reload_conf();

# 同步元数据到数据节点
SELECT * from start_metadata_sync_to_node('192.168.0.2', 15432);

# 查看同步情况
repl1=# select * from pg_dist_node;
nodeid | groupid |  nodename   | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster | metadatasynced | shouldhaveshards
--------+---------+-------------+----------+----------+-------------+----------+----------+-------------+----------------+------------------
      1 |       1 | 192.168.0.1 |    15432 | default  | f           | t        | primary  | default     | f              | t
      3 |       3 | 192.168.0.3 |    15432 | default  | f           | t        | primary  | default     | f              | t
      2 |       2 | 192.168.0.2 |    15432 | default  | t           | t        | primary  | default     | t              | t
(3 rows)

建表测试

repl1=# create table repl_model_streaming(a int primary key, b int , c int);
repl1=# select create_distributed_table('repl_model_streaming', 'a');
ERROR:  replication factors above one are incompatible with the streaming replication model
HINT:  Try again after reducing "citus.shard_replication_factor" to one or setting "citus.replication_model" to "statement".

可见,citus的流复制模式不可以和多副本模式同时使用

副本为1时可以,但是副本为1等同于没有副本

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,752评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,100评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,244评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,099评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,210评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,307评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,346评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,133评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,546评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,849评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,019评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,702评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,331评论 3 319
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,030评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,260评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,871评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,898评论 2 351