Citus总结：高可用

2022-04-13 09:57:24

1. Citus的复制功能

前面有提到，Citus支持两种数据复制方案：

Citus的Shard Replication：通过将DML语句复制到多个Worker节点执行，实现对shard分片数据的复制，仅适用于append-only的负载；当某个Worker节点故障时，Coordinator节点会自动将查询请求转发到其他副本节点以实现高可用；
PostgreSQL的Streaming Replication：通过将Primary节点的WAL记录持续的复制到Standby节点，实现对Primary节点的完整复制，适用于负载较重的OLTP场景；

为什么会同时存在两种方案呢？可以看看Citus复制功能的演进过程。

在早期的版本中，Citus的主要应用场景是实时数据分析场景，用户批量的导入数据，并通过Citus进行实时数据查询分析，数据不需要修改，是完全Append-only的场景。

Append-Only的场景，各分片数据只需要在完成导入后是一致的就行，为了大化导入性能，可以从客户端直接并行导入。

这个阶段，Citus导入数据的流程如下：

随着使用Citus的人越来越多，对于提供数据更新能力的需求也越来越多。为了提供数据更新能力，Citus需要解决两个主要的问题：

为了解决引入数据更新能力的问题，Citus将更新操作集中到了Coordinator节点，由集中的Coordinator节点处理并发冲突和故障处理。

此时，数据的多副本复制，改成了由Coordinator节点复制DML语句到多个Worker节点执行。

随着使用Citus的场景增加，例如多租户的场景，Citus引入了Co-located亲和性共存能力，可以把相同租户的数据亲和性存储在同一个Worker节点，方便支持Join查询，Rollup、外键约束等特性。

此时，前面基于复制Statment的复制方案就会碰到问题，当某个Shard因为短时故障被标记为invalid时，应该如何处理处于同一个Co-located亲和组的其他Shard？

这是一个两难的问题，为了安全起见，Citus在6.0版本中把复制因子的默认值从2改为了1，就是因为多租户场景下可能会产生违反外键约束的问题。

现在，Citus推荐的是使用PostgreSQL的Streaming Replication，如下图所示，Streaming Replication是primary-based replication，由主节点解决并发控制问题。

如前面描述，Streaming Replication是PostgreSQL的内置特性，通过将WAL记录持续复制到Standby节点，建立Hot Standby备份节点。

在云上，也可以使用云提供商的镜像卷能力，当Primary节点故障时，在对应备份卷的主机上拉起数据库进程接管业务。

如果对RTO业务恢复时间不太敏感，也可以采用将WAL日志增量备份到对象存储的方式，本方案的成本更低，故障后，拉起对应计算节点，从对象存储恢复日志并重放数据即可。