号外:Citus发布了8.x版本,支持PostgreSQL11。
Citus适合存放数据量较大的情形,不上亿都不好意思往Citus中放,或者说更适合放单节点,存储如此大量的数据,如果不做好数据备份或高可用,数据丢失损失不会小,所以我们就来看看Citus是怎么保护数据的。Citus集群中节点分为两种角色:Worker节点和Coordinator节点,我们分别展开来看,如何实现Worker节点和Coordinator节点的高可用。
worker节点故障
Citus处理worker节点宕掉的方法是保存一份数据的多个副本,Citus支持两种形式的备份:PostgreSQL的流式复制(Stream Replication)、Citus的分片复制(Shard Replication)。
PostgreSQL的流式复制
流式复制是指持续的发送WAL XLOG到一个或多个备份服务器,让它们的数据始终保持同步最新,在9.0版本加入的功能。
配置流式复制账户
在备份服务器上创建用于接收WAL XLOG的用户,该用户需要具有“REPLICATION”权限,但最好不要给与过高权限,如“SUPERUSER”,该权限允许用户修改主服务器的数据,可能会引发不必要的安全问题。
CREATE USER sr_user WITH REPLICATION;
允许备份服务器访问主服务器
pg_hba.conf中添加一行,允许备份服务器访问(假设备份服务器IP是192.168.0.17):
# TYPE DATABASE USER ADDRESS METHOD
host replication sr_user 192.168.0.17/32 md5
配置备份服务器访问主服务器
修改备份服务器的revovery.conf,添加主服务器连接信息(假设主服务器IP为192.168.0.1,数据库端口5432,用户名是p_user,密码是p_user_pass)。
primary_conninfo = 'host=192.168.1.50 port=5432 user=p_user password=p_user_pass'
OK,现在重启主服务器和你的备份服务器,观察数据是否同步。
TODO
Citus的分片复制
Citus将每个数据分片复制两份或多份,分布到不同的worker节点上,如果其中存储相同分片的一个worker节点宕掉,Coordinator节点会将查询路由到有相同分片的正常worker节点。要使用Citus的分片复制功能,需要创建分布式表之前设置启用分片复制功能,将“shard_replication_factor”,也就是每个分片的副本数量,设置为2或者更高,以支持更好的容错性。
SET citus.shard_replication_factor = 2;
如果没有开启分片复制功能,每个分片默认只有一个副本,也就是说,如果某个node节点宕掉,那么数据肯定会不完整,查询将会失败:
relation "test_shard_replication_102182" does not exist
relation "test_shard_replication_102185" does not exist
······
relation "test_shard_replication_102189" does not exist
Coordinator节点故障
Coordinator节点作用主要是维护元数据,这些元数据记录着各个节点地址、状态,以及数据的各个分片副本在各个worker节点的分布情况,并不会实际存储业务数据,所以其维护的数据的总体积不大,较为容易备份和恢复,所以Citus本身并没有存储其副本,没有给出高可用的方案,但我们还是可以利用PostgreSQL的流式复制实现Coordinator节点的高可用,当然也有一些其它的备份方法,但需要手动进行数据和Coordinator节点的恢复。
总结
无论是Worker节点故障还是Coordinator节点故障,我们都可以利用PostgreSQL本身的流式复制(Stream Replication)来实现一定程度的高可用,由于所有的业务数据都会存放在Worker节点,Citus还提供了分片副本的方式来实现单点故障的高可用。