Citus数据分片分布研究（二 副本与故障）
2024-05-10 15:59:51
（本文中凡是未显式指出的SQL，均在协调节点上执行）
工作节点
mydb1=# SELECT * FROM master_get_active_worker_nodes();node_name | node_port
---------------+-----------192.168.7.131 | 5432192.168.7.135 | 5432192.168.7.136 | 5432192.168.7.137 | 5432192.168.7.133 | 5432192.168.7.132 | 5432192.168.7.134 | 5432192.168.7.130 | 5432
(8 rows)创建表test_table
create table test_table(id int, name varchar(16));配置分片原则
SELECT master_create_distributed_table('test_table', 'id', 'hash');根据分片数和副本数进行分片
SELECT master_create_worker_shards('test_table', 8, 2);查看分片
mydb1=# SELECT * from pg_dist_shard order by shardid; logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
--------------+---------+--------------+---------------+---------------test_table | 102032 | t | -2147483648 | -1610612737test_table | 102033 | t | -1610612736 | -1073741825test_table | 102034 | t | -1073741824 | -536870913test_table | 102035 | t | -536870912 | -1test_table | 102036 | t | 0 | 536870911test_table | 102037 | t | 536870912 | 1073741823test_table | 102038 | t | 1073741824 | 1610612735test_table | 102039 | t | 1610612736 | 2147483647
(8 rows)可见一共有8个分片。
查看分片分布
mydb1=# SELECT * from pg_dist_shard_placement order by shardid, placementid;shardid | shardstate | shardlength | nodename | nodeport | placementid
---------+------------+-------------+---------------+----------+-------------102032 | 1 | 0 | 192.168.7.130 | 5432 | 33102032 | 1 | 0 | 192.168.7.131 | 5432 | 34102033 | 1 | 0 | 192.168.7.131 | 5432 | 35102033 | 1 | 0 | 192.168.7.132 | 5432 | 36102034 | 1 | 0 | 192.168.7.132 | 5432 | 37102034 | 1 | 0 | 192.168.7.133 | 5432 | 38102035 | 1 | 0 | 192.168.7.133 | 5432 | 39102035 | 1 | 0 | 192.168.7.134 | 5432 | 40102036 | 1 | 0 | 192.168.7.134 | 5432 | 41102036 | 1 | 0 | 192.168.7.135 | 5432 | 42102037 | 1 | 0 | 192.168.7.135 | 5432 | 43102037 | 1 | 0 | 192.168.7.136 | 5432 | 44102038 | 1 | 0 | 192.168.7.136 | 5432 | 45102038 | 1 | 0 | 192.168.7.137 | 5432 | 46102039 | 1 | 0 | 192.168.7.137 | 5432 | 47102039 | 1 | 0 | 192.168.7.130 | 5432 | 48
(16 rows)可见每个分片有2个副本，分布在相邻的不同工作节点上。
插入8条记录
mydb1=# select * from test_table order by id;id | name
----+------1 | a2 | b3 | c4 | d5 | e6 | f7 | g8 | h
(8 rows)在工作节点上查询分片内的数据
在节点192.168.7.130和节点192.168.7.131上查询分片102032（及其副本），查询结果相同。
mydb1=# select * from test_table_102032;
id | name
----+------
1 | a
8 | h
(2 rows)直接向工作节点写数据（故意）造成数据不同步
在节点192.168.7.130上执行：
mydb1=# INSERT INTO test_table_102032 VALUES(111,'111');
INSERT 0 1
mydb1=# select * from test_table_102032;id | name
-----+------1 | a8 | h111 | 111
(3 rows)在节点192.168.7.131上执行：
mydb1=# INSERT INTO test_table_102032 VALUES(222,'222');
INSERT 0 1
mydb1=# select * from test_table_102032;id | name
-----+------1 | a8 | h222 | 222
(3 rows)在协调节点上查看结果
mydb1=# select * from test_table order by id;id | name
-----+------1 | a2 | b3 | c4 | d5 | e6 | f7 | g8 | h111 | 111
(9 rows)可以判断：协调节点通常只从主工作节点取数据。
人为拔出“主工作节点”网线
mydb1=# select * from test_table order by id;
WARNING: could not establish asynchronous connection after 5000 msid | name
-----+------1 | a2 | b3 | c4 | d5 | e6 | f7 | g8 | h222 | 222
(9 rows)可以判断：当无法从主工作节点（192.168.7.130）获取数据时，协调节点会从副本工作节点（192.168.7.131）取数据。
将主工作节点网络恢复后，再次查询
mydb1=# select * from test_table order by id;id | name
-----+------1 | a2 | b3 | c4 | d5 | e6 | f7 | g8 | h111 | 111
(9 rows)可以判断：协调节点自动切回了主工作节点
在工作节点掉线的过程中，如果不发生涉及掉线节点的写操作，分片信息和分片分布信息未发生变化。（只涉及其他节点的写操作，没有影响）
mydb1=# INSERT INTO test_table VALUES(99,'99');
INSERT 0 1
mydb1=# SELECT * from pg_dist_shard order by shardid;logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
--------------+---------+--------------+---------------+---------------test_table | 102032 | t | -2147483648 | -1610612737test_table | 102033 | t | -1610612736 | -1073741825test_table | 102034 | t | -1073741824 | -536870913test_table | 102035 | t | -536870912 | -1test_table | 102036 | t | 0 | 536870911test_table | 102037 | t | 536870912 | 1073741823test_table | 102038 | t | 1073741824 | 1610612735test_table | 102039 | t | 1610612736 | 2147483647
(8 rows)mydb1=# SELECT * from pg_dist_shard_placement order by shardid, placementid;shardid | shardstate | shardlength | nodename | nodeport | placementid
---------+------------+-------------+---------------+----------+-------------102032 | 1 | 0 | 192.168.7.130 | 5432 | 33102032 | 1 | 0 | 192.168.7.131 | 5432 | 34102033 | 1 | 0 | 192.168.7.131 | 5432 | 35102033 | 1 | 0 | 192.168.7.132 | 5432 | 36102034 | 1 | 0 | 192.168.7.132 | 5432 | 37102034 | 1 | 0 | 192.168.7.133 | 5432 | 38102035 | 1 | 0 | 192.168.7.133 | 5432 | 39102035 | 1 | 0 | 192.168.7.134 | 5432 | 40102036 | 1 | 0 | 192.168.7.134 | 5432 | 41102036 | 1 | 0 | 192.168.7.135 | 5432 | 42102037 | 1 | 0 | 192.168.7.135 | 5432 | 43102037 | 1 | 0 | 192.168.7.136 | 5432 | 44102038 | 1 | 0 | 192.168.7.136 | 5432 | 45102038 | 1 | 0 | 192.168.7.137 | 5432 | 46102039 | 1 | 0 | 192.168.7.137 | 5432 | 47102039 | 1 | 0 | 192.168.7.130 | 5432 | 48
(16 rows)在工作节点掉线的过程中，如果发生了涉及掉线节点的写操作，分片分布信息中“分片状态”发生了变化。（从1变成3）
mydb1=# INSERT INTO test_table VALUES(1,'1111111');
WARNING: connection error: 192.168.7.130:5432
DETAIL: could not send data to server: No route to host
could not send SSL negotiation packet: No route to host
INSERT 0 1
mydb1=# SELECT * from pg_dist_shard order by shardid;logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
--------------+---------+--------------+---------------+---------------test_table | 102032 | t | -2147483648 | -1610612737test_table | 102033 | t | -1610612736 | -1073741825test_table | 102034 | t | -1073741824 | -536870913test_table | 102035 | t | -536870912 | -1test_table | 102036 | t | 0 | 536870911test_table | 102037 | t | 536870912 | 1073741823test_table | 102038 | t | 1073741824 | 1610612735test_table | 102039 | t | 1610612736 | 2147483647
(8 rows)mydb1=# SELECT * from pg_dist_shard_placement order by shardid, placementid;shardid | shardstate | shardlength | nodename | nodeport | placementid
---------+------------+-------------+---------------+----------+-------------102032 | 3 | 0 | 192.168.7.130 | 5432 | 33102032 | 1 | 0 | 192.168.7.131 | 5432 | 34102033 | 1 | 0 | 192.168.7.131 | 5432 | 35102033 | 1 | 0 | 192.168.7.132 | 5432 | 36102034 | 1 | 0 | 192.168.7.132 | 5432 | 37102034 | 1 | 0 | 192.168.7.133 | 5432 | 38102035 | 1 | 0 | 192.168.7.133 | 5432 | 39102035 | 1 | 0 | 192.168.7.134 | 5432 | 40102036 | 1 | 0 | 192.168.7.134 | 5432 | 41102036 | 1 | 0 | 192.168.7.135 | 5432 | 42102037 | 1 | 0 | 192.168.7.135 | 5432 | 43102037 | 1 | 0 | 192.168.7.136 | 5432 | 44102038 | 1 | 0 | 192.168.7.136 | 5432 | 45102038 | 1 | 0 | 192.168.7.137 | 5432 | 46102039 | 1 | 0 | 192.168.7.137 | 5432 | 47102039 | 1 | 0 | 192.168.7.130 | 5432 | 48
(16 rows)此时再恢复原“主工作节点”，发现标记并未恢复；且协调节点仍会从原先的“副本工作节点”取得数据。
在节点192.168.7.130上执行：
mydb1=# select * from test_table_102032 order by id;
id | name
-----+------
1 | a
8 | h
111 | 111
(3 rows)缺少记录 (1, ‘1111111’)
在节点192.168.7.131上执行：
mydb1=# select * from test_table_102032 order by id;
id | name
-----+---------
1 | a
1 | 1111111
8 | h
222 | 222
(4 rows)在协调节点上执行：
mydb1=# select * from test_table order by id;id | name
-----+---------1 | a1 | 11111112 | b3 | c4 | d5 | e6 | f7 | g8 | h99 | 99222 | 222 <-----可见是从131上取的数据
(11 rows)查看分片分布状态：
mydb1=# SELECT * from pg_dist_shard_placement order by shardid, placementid;shardid | shardstate | shardlength | nodename | nodeport | placementid
---------+------------+-------------+---------------+----------+-------------102032 | 3 | 0 | 192.168.7.130 | 5432 | 33102032 | 1 | 0 | 192.168.7.131 | 5432 | 34102033 | 1 | 0 | 192.168.7.131 | 5432 | 35102033 | 1 | 0 | 192.168.7.132 | 5432 | 36102034 | 1 | 0 | 192.168.7.132 | 5432 | 37102034 | 1 | 0 | 192.168.7.133 | 5432 | 38102035 | 1 | 0 | 192.168.7.133 | 5432 | 39102035 | 1 | 0 | 192.168.7.134 | 5432 | 40102036 | 1 | 0 | 192.168.7.134 | 5432 | 41102036 | 1 | 0 | 192.168.7.135 | 5432 | 42102037 | 1 | 0 | 192.168.7.135 | 5432 | 43102037 | 1 | 0 | 192.168.7.136 | 5432 | 44102038 | 1 | 0 | 192.168.7.136 | 5432 | 45102038 | 1 | 0 | 192.168.7.137 | 5432 | 46102039 | 1 | 0 | 192.168.7.137 | 5432 | 47102039 | 1 | 0 | 192.168.7.130 | 5432 | 48
(16 rows)Citus数据分片分布研究（二 副本与故障）相关推荐
- Citus数据分片分布研究（三 节点故障的手动修复）
服务器主机配置: CPU:单核2GHz RAM:2GB DISK:30GB HDD Citus部署配置: Coordinator X 1 (192.168.7.129) Worker X 2 (192 ...
- Citus数据分片分布研究（一 在工作节点直接操作表）
(本文中凡是未显式指出的SQL,均在协调节点上执行) 工作节点 mydb1=# SELECT * FROM master_get_active_worker_nodes();node_name | n ...
- 判断数据是否服从某一分布（二）——简单易用fitdistrplus包
一.对数据的分布进行初步判断 1.1 原理 对于不同的分布,有特定的偏度(skewness)和峰度(kurtosis),正态分布.均匀分布.逻辑斯谛分布.指数分布的偏度和峰度都是特定的值,在偏 ...
- Py之seaborn：数据可视化seaborn库(二)的组合图可视化之密度图/核密度图分布可视化、箱型图/散点图、小提琴图/散点图组合可视化的简介、使用方法之最强攻略(建议收藏)
Py之seaborn:数据可视化seaborn库(二)的组合图可视化之密度图/核密度图分布可视化.箱型图/散点图.小提琴图/散点图组合可视化的简介.使用方法之最强攻略(建议收藏) 目录 二.组合图可视 ...
- 大数据图数据库之数据分片
节选自<大数据日知录:架构与算法>十四章,书籍目录在此 对于海量待挖掘数据,在分布式计算环境下,首先面临的问题就是如何将数据比较均匀地分配到不同的服务器上.对于非图数据来说,这个问题解决起 ...
- mongodb数据合并设计_「时间序列数据」和MongoDB(二)-模式设计最佳实践
在上一篇博客文章时间序列数据与MongoDB:第一部分-简介中,我们介绍了时间序列数据的概念,然后介绍了一些可以用于帮助收集时间序列应用程序需求的发现问题.对这些问题的回答有助于指导支持大容量生产应用 ...
- 水环境模型与大数据技术融合研究
点击上方蓝字关注我们 水环境模型与大数据技术融合研究 马金锋1, 饶凯锋1, 李若男1,2, 张京1, 郑华1,2 1 中国科学院生态环境研究中心城市与区域生态国家重点实验室,北京 100085 2 ...
- 一文讲透，分布式系统的数据分片难题
一般来说,数据分片是将整体数据分摊在多个存储设备上,这样每个存储设备的数据量相对就会小很多,以此满足系统的性能需求.本文主要讨论数据分片的三个问题:如何做数据分片.数据分片的特征值以及数据分片元数据的 ...
- 2021年大数据Kafka（十二）：❤️Kafka配额限速机制❤️
全网最详细的大数据Kafka文章系列,强烈建议收藏加关注! 新文章都已经列出历史文章目录,帮助大家回顾前面的知识重点. 目录 系列历史文章 Kafka配额限速机制 限制producer端的速率 限制c ...
最新文章
- 2021年大数据ELK（四）：Lucene的美文搜索案例
- springboot controller 参数绑定
- javascript弹出窗口居中代码
- c语言或者cpp中位运算的技巧
- MySQL 七天 学_7天玩转
- GDCM：gdcm::FileStreamer的测试程序
- 天线的起源与发展历史
- pdf文档遇到了共享冲突_如何将链接共享为PDF格式的Google文档链接
- dotnetClub 的前世今生
- 快给你的代码来点彩虹屁
- k8s极简史：K8s多集群技术发展的历史、现状与未来
- Linux服务器SSH免密登录
- netmiko可以连接的设备有哪些_气体报警器可以联动哪些设备
- php基本语法实验总结,PHP总结（一）基本语法内容
- L1-078 吉老师的回归 (15 分)-PAT 团体程序设计天梯赛 GPLT
- vue学习-MVVM的实现原理
- 怎么配置php发送邮件环境,如何配置PHP发送电子邮件？
- 互联网协议 — Ethernet 以太网协议
- unity功能开发——实名认证
- 正高职称相当于公务员的什么级别？为什么有人说评上正高就值了