Question

我们正在使用3节点cassandra集群（不同虚拟机上的每个节点），并且当前正在调查写入和读取操作期间的故障转移时间，以防其中一个节点死亡。当正常关闭一个节点时，故障转移时间非常好，但是，在杀死节点时（通过关闭VM），测试期间的延迟大约为12秒。我想这与tcp超时有关？

有没有办法调整这个？

修改目前我们正在使用Cassandra版本2.0.10。我们使用的是java客户端驱动程序，版本2.1.9。

更详细地描述情况：写入/读取操作使用 QUROUM 一致性级别执行，复制因子为3.集群由3个节点（c1,c2,c3）组成，每个节点位于不同的主机（VM）上。客户端驱动程序已连接到c1。在测试期间，我关闭了c2的主机。从那时起，我们发现客户端正在阻止＆gt; 12秒，直到其他节点意识到c2已消失。所以我认为这不是客户端问题，因为客户端已连接到节点c1，该节点仍在此方案中运行。

编辑：我不相信在VM中运行cassandra会影响网络堆栈。实际上，杀死VM会产生TCP连接未终止的影响。在这种情况下，远程主机只能通过一些超时机制（应用程序级协议超时或TCP超时）注意到这一点。如果进程在操作系统级别被终止，则操作系统的TCP堆栈将负责终止TCP连接（具有TCP重置的IMHO），使远程主机立即得到有关故障的通知。但是，即使在由于硬件故障导致主机崩溃的情况下，或者由于拔出的网络电缆导致主机断开连接（在两种情况下TCP连接都不会立即终止）的情况下，故障转移时间也很重要。低。我试图 sigkill VM内部的cassandra进程。在这种情况下，故障转移时间约为600毫秒，这很好。

亲切的问候

Answer 1

在正常关闭一个节点时，故障转移时间非常好，但是，在终止节点时（通过关闭VM），测试期间的延迟大约为12秒

12秒是非常巨大的价值。在进一步调查之前的一些问题

你的Cassandra版本是什么？自版本 2.0.2 以来，有一种推测性重试机制可帮助减少此类故障转移方案的延迟：http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2
您正在使用的客户端驱动程序是什么（java？c＃？version？）。通常使用正确配置的负载平衡策略，当节点关闭时，客户端将通过重新路由到另一个副本来自动重试该查询。在驾驶员方面也实施了投机性重试：http://datastax.github.io/java-driver/manual/speculative_execution/

编辑：对于要标记为关闭的节点，八卦协议正在使用phi accrual检测器。该算法不是具有二进制状态（UP / DOWN），而是调整怀疑级别，如果该值高于阈值，则认为该节点已关闭

由于微网络问题，该算法对于避免标记节点是必要的。

在cassandra.yaml文件中查找此配置：

# phi value that must be reached for a host to be marked down.
# most users should never need to adjust this.
# phi_convict_threshold: 8

另一个问题是：您在驱动程序中使用的负载均衡策略？你是否使用了投机重试政策？

Cassandra改善了故障转移时间

1 个答案: