我使用官方的docker和docker compose指令设置了citus 11集群。我将集群扩展到5个工作节点，并创建了一个复制因子为3的分布式表。
如果我关闭一个工作节点，我希望Citus集群能够工作。但当我通过阻止一名工人来测试这一点时。整张桌子都停下来工作了。像select*或select count(*(这样的简单查询将被阻止，直到我重新启动工作节点。
所以，我的问题是，这是否意味着Citus现在没有内置的高可用性功能？我对分片、复制和分布式查询引擎感到困惑。理论上，即使一个节点出现故障，集群中仍有2个数据副本。Citus可以很容易地找到这些复制碎片并从中查询数据。这就是大多数分布式数据库的工作方式。
如果是这样的话，增加服务器数量将大大增加整个集群的故障率，然后如果我使用旧的热备用节点来复制每个工作节点，这将大大增加预算。
请告诉我我错了。我正在尝试规划SaaS服务，而关系数据库现在是系统的唯一瓶颈。所以我正试图制作一个"；可扩展解决方案"；具有完善的备份/恢复功能和高可用性。
Citus具有读取查询的本地高可用性，但如果一个节点出现故障，写入查询将失败(否则，它们将使用不同的数据(。
我的第一个问题是：你是如何阻止你的工人的？你停止了postgres过程吗？你关掉机器了吗？你屏蔽了所有网络流量吗？
在最后两种情况下，Linux内核可能还没有报告TCP套接字已损坏，因此citus只是继续等待响应。这在许多分布式系统中都需要考虑，并且需要为客户端配置适当的TCP超时。这可以通过在postgresql.conf文件中放入以下内容并重新加载/重新启动postgres:为citus完成：
citus.node_conninfo = 'keepalives=1 keepalives_idle=30 keepalives_interval=15 keepalives_count=2 tcp_user_timeout=10000 connect_timeout=25 sslmode=require'
这些设置做3件事：
- 检测到空闲缓存连接在另一侧无响应后最多60秒断开(30+15*2(
- 如果对方在10秒内没有确认任何TCP消息，则连接被标记为断开
- 在连接尝试被视为失败之前，请等待20秒成功建立连接
如果您想要更严格的超时，您可以相应地更改这些值。
推荐什么
不过，一般来说，对于高可用性，我们建议使用常规的postgres高可用性解决方案，如Patroni或pg_auto_failover。这些也可以用于写操作的HA。其中一些有用的资源是：https://laravel.wiki/62687acd9a725.html