号外：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还提供了分片副本的方式来实现单点故障的高可用。
