postgres 数据库 citus 集群分片

 文档结构：

 

 

如下前言来自网络

前言

何时须要考虑作数据切分？

一、能不切分尽可能不要切分

1. 并非全部表都须要进行切分，主要仍是看数据的增加速度。切分后会在某种程度上提高业务的复杂度，数据库除了承载数据的存储和查询外，协助业务更好的实现需求也是其重要工做之一。
2. 不到万不得已不用轻易使用分库分表这个大招，避免"过分设计"和"过早优化"。分库分表以前，不要为分而分，先尽力去作力所能及的事情，例如：升级硬件、升级网络、读写分离、索引优化等等。当数据量达到单表的瓶颈时候，再考虑分库分表。

二、数据量过大，正常运维影响业务访问

这里说的运维，指：

1. 对数据库备份，若是单表太大，备份时须要大量的磁盘IO和网络IO。例如1T的数据，网络传输占50MB时候，须要20000秒才能传输完毕，整个过程的风险都是比较高的
2. 对一个很大的表进行DDL修改时，会锁住全表，这个时间会很长，这段时间业务不能访问此表，影响很大。在此操做过程当中，都算为风险时间。将数据表拆分，总量减小，有助于下降这个风险。
3. 大表会常常访问与更新，就更有可能出现锁等待。将数据切分，用空间换时间，变相下降访问压力

三、随着业务发展，须要对某些字段垂直拆分

举个例子，假如项目一开始设计的用户表以下：

id bigint #用户的ID

name varchar #用户的名字

last_login_time datetime #最近登陆时间

personal_info text #私人信息

….. #其余信息字段

在项目初始阶段，这种设计是知足简单的业务需求的，也方便快速迭代开发。而当业务快速发展时，用户量从10w激增到10亿，用户很是的活跃，每次登陆会更新 last_login_name 字段，使得 user 表被不断update，压力很大。而其余字段：id, name, personal_info 是不变的或不多更新的，此时在业务角度，就要将 last_login_time 拆分出去，新建一个 user_time 表。

personal_info 属性是更新和查询频率较低的，而且text字段占据了太多的空间。这时候，就要对此垂直拆分出 user_ext 表了。

四、数据量快速增加

1. 随着业务的快速发展，单表中的数据量会持续增加，当性能接近瓶颈时，就须要考虑水平切分，作分库分表了。此时必定要选择合适的切分规则，提早预估好数据容量

五、安全性和可用性

鸡蛋不要放在一个篮子里。在业务层面上垂直切分，将不相关的业务的数据库分隔，由于每一个业务的数据量、访问量都不一样，不能由于一个业务把数据库搞挂而牵连到其余业务。利用水平切分，当一个数据库出现问题时，不会影响到100%的用户，每一个库只承担业务的一部分数据，这样总体的可用性就能提升。

六、索引效率

随着数据量的增长，经过辅助索引查找的数据愈来愈多，大部分是须要进行回表操做，不能直接经过辅助索引找到数据，当数据量很是大时，回表查找将会消耗大量的时间，因为Oracle,MySQL,Postgresql查询优化器是基于cost代价模型来设计的，当查询返回值大于必定比例，执行优化器会选择走全表扫描

 

Citus可以横向扩展多租户（b2b）数据库，或者构建实时应用程序。citus使用分片，复制，查询并行化扩展postgres跨服务器来实现这一点，它是之前 pg_shard的升级版本。

Citus适用两种应用场景，这两种应用场景对应两种数据模型:对租户对应程序和实时分析

多租户适用于B2B应用场景。

 

一. 安装citus集群

有关苏宁易购的citus:

http://postgres.cn/downfiles/pgconf_2018/PostgresChina2018_%E9%99%88%E5%8D%8E%E5%86%9B_citus%E5%9C%A8%E8%8B%8F%E5%AE%81%E7%9A%84%E5%A4%A7%E8%A7%84%E6%A8%A1%E5%BA%94%E7%94%A8.pdf

IP	操做系统	端口	Citus版本
192.168.10.41  /master	CentOS release 6.10	5432	7.2
192.168.10.51  /woker	CentOS release 6.10	5433	7.2
192.168.10.61  /woker	CentOS release 6.10	5434	7.2

 

步骤在全部节点上执行（我是root身份执行的）

curl https://install.citusdata.com/community/rpm.sh | sudo bash

 

 

 yum install -y citus72_10

 

##yum install -y citus83_11 （我安装10的版本）

 

 

 

 

配置postgres环境变量

集群官方网站来自：

https://docs.citusdata.com/en/stable/installation/multi_machine_rhel.html

单机：https://docs.citusdata.com/en/stable/installation/single_machine_rhel.html

如下是三台都须要操做的步骤

实例初始化：

service postgresql-10 initdb || sudo /usr/pgsql-10/bin/postgresql-10-setup initdb

 

 

修改vi /var/lib/pgsql/10/data/postgresql.conf配置，加入如下内容：

shared_preload_libraries='citus'

若是又多个shared_proload_librarues，shared_preload_libraries='citus'排在第一。

修改其余参数，好比监听参数。

 

而且修改pg_hba.conf 参数（加入如下）。

hostnossl    all             all             0.0.0.0/0               trust

启动postgres-10

service postgresql-10 start

chkconfig postgresql-10 on

 

 

配置环境变量：

export PATH=/usr/pgsql-10/bin:$PATH:

查看安装的数据库：

psql -p5432

 

 

create extension citus;

 

select * from pg_extension ;

 

 

二. 在协调节点(主节点)上执行的步骤

a. 节点常规操做

SELECT * from master_add_node('192.168.10.51',5433);

SELECT * from master_add_node('192.168.10.61',5434);

 

 

查看添加的节点：

SELECT * FROM master_get_active_worker_nodes();

 

 

若是须要时删除节点：

好比说删除61 5434：

 SELECT * from master_remove_node('192.168.10.61',5434);

查看：

 

 

 

已经删除了，只剩一个了。

 

禁用某个节点：

select master_disable_node('192.168.10.51',5433);

 

 

 

只看导5434端口的节点了，5433的没有活动。

 

从新启用节点：

select master_activate_node('192.168.10.51',5433);

 

 

 

 

 

b. 分布式集群测试

创建分布式表：

注意，cutis不可以建立数据库：

create database test;  须要全部节点建立数据库

create extension citus;   而且数据库建立插件

 

 

 

主节点上操做：

create table test(id int, name varchar(16));

查看默认分片数：

show citus.shard_count;

 

 

 

默认分片数是32，默认是采用hash mod 的分布方式，能够根绝实际状况进行调整，查了不少资料，官方建议OLTP场景(带分片字段SQL)小负载（小于100GB）32；大负载64或128；我的比较赞同的是：cpu核数*物理节点的分片数*物理节点数

 

将表test 分片（主库）

 SELECT master_create_distributed_table('test', 'id', 'hash');

 

 

 

设定分片个数（2）以及每一个分片副本数（2）

SELECT master_create_worker_shards('test', 2, 2);

 

 

 

执行完后查看节点表：

主节点：

 

 

 

能够看出来，数据所有再子节点

节点2：

 

 

 

节点3：

 

 

 

好比我插入10条数据：

主节点

insert into test select *,'a' from generate_series(1,10);

 

发现工做节点两便都是：

 

 

 

insert into test select id+10,name from test;

 

 

 

建索引：

 

 

 

子节点：

 

 

 

c. Citus参数以及试图

查看试图：

 

有关参数，大多数的经常使用的都是

pg_dist_ 前缀的参数。

查看元数据的几个试图：

pg_dist_partition

pg_dist_shard

pg_dist_shard_placement

 

参数：

set citus.enable_repartition_joins = on

这个能够开启，开启分片表的亲和，能够优化设计夺标的sql和事务，也支持sql下推。

“Citus Maintenance Daemon”进程自动检测和处理分布式死锁。

 

citus.shard_replication_factor 分片的副本，默认值1

citus.shard_count  分偏数量 默认值32

citus.task_executor_type 它值为real-time 和task-tracker，默认为real-time,在跨多个分片的聚合和共同定位链接的查询性能最好。

idle_in_transaction_session_timeout 未防止链接资源被耗尽，能够进行设置事务链接时间，默认毫秒。

 

查看根据对应的分零篇键值，查找分片：

select get_shard_id_for_distribution_column('t',100);

 

 

Id=100的值分片为t_102018

 

查看建立分片函数：

create_distributed_table

 

d. Citus故障测试

若是主节点服务器坏点怎么处理？

哈哈，这个最开始架构选取的时候，就应该设置主备模式，利用VIP，主节点的citus换掉了，备节点接管服务。

 

其余节点点服务器down掉

 

模拟 51节点down 掉，主节点有数据进行插入。

 

 

 

 

 

插入数据的时候，有提示51上异常，可是仍是插入成功了。

 

起来以后，查看分片的状况：

 

SELECT * from pg_dist_shard_placement order by shardid, placementid;

 

 

 

明显应该都是1的，直接把节点2，102008，102009 这两个从新同步一下

主节点执行：

把节点3的数据拷贝导节点2，主节点执行：

 

SELECT master_copy_shard_placement(102008, '192.168.10.61', 5434, '192.168.10.51', 5433);

SELECT master_copy_shard_placement(102009, '192.168.10.61', 5434, '192.168.10.51', 5433);

 

 

 

子节点：

 

 

 

主节点：

 

已经同步正常。

原文出处：https://www.cnblogs.com/hmwh/p/11651333.html