Cassandra 改善故障转移时间
Cassandra improve failover time
我们正在使用 3 节点 cassandra 集群（每个节点在不同的虚拟机上），目前正在调查写入和读取操作期间的故障转移时间，以防其中一个节点死亡。
优雅地关闭一个节点时，故障转移时间非常好，但是，当杀死一个节点（通过关闭 VM）时，测试期间的延迟约为 12 秒。我猜这与 tcp 超时有关？
有什么办法可以调整吗？
编辑：
目前我们使用的是 Cassandra 版本 2.0.10。
我们正在使用 java 客户端驱动程序，版本 2.1.9.
更详细地描述一下情况：
write/read 操作使用 QUROUM 一致性级别执行，复制因子为 3。集群由 3 个节点 (c1,c2,c3) 组成，每个节点位于不同的主机上（虚拟机）。客户端驱动程序连接到 c1。在测试期间，我关闭了 c2 的主机。从那时起，我们观察到客户端阻塞了 > 12 秒，直到其他节点意识到 c2 消失了。所以我认为这不是客户端问题，因为客户端连接到节点 c1，在这种情况下它仍然是 运行。
编辑： 我不相信 VM 中的 运行 cassandra 会影响网络堆栈。事实上，终止 VM 的效果是 TCP 连接不会终止。在这种情况下，远程主机只能通过某种超时机制（应用程序级协议超时或 TCP 超时）注意到这一点。
如果进程在 OS 级别被杀死，OS 的 TCP 堆栈将负责终止 TCP 连接（恕我直言，TCP 重置），使远程主机能够立即收到有关失败的通知。
然而，重要的是，即使在主机因硬件故障而崩溃，或主机因网络电缆被拔出而断开连接的情况下（在这两种情况下，TCP 连接都不会立即终止），故障转移时间仍然是低的。我已经尝试 sigkill VM 中的 cassandra 进程。在这种情况下，故障转移时间约为 600 毫秒，这很好。
亲切的问候
Failover times are pretty good when shutting down one node gracefully, however, when killing a node (by shutting down the VM) the latency during the tests is about 12 seconds
12 秒是一个相当大的值。进一步调查前的一些问题
你的 Cassandra 版本是多少？自版本 2.0.2 以来，有一种推测重试机制有助于减少此类故障转移场景的延迟：http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2
您使用的客户端驱动程序是什么（java？c#？版本？）。通常使用正确配置的负载平衡策略，当节点关闭时，客户端将通过重新路由到另一个副本来自动重试查询。在驱动程序端也实现了推测性重试：http://datastax.github.io/java-driver/manual/speculative_execution/
编辑：对于要标记为关闭的节点，八卦协议正在使用 phi 应计检测器。该算法不具有二进制状态 (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
另一个问题是：您使用驱动程序的什么负载平衡策略？您是否使用了推测重试策略？
我们正在使用 3 节点 cassandra 集群（每个节点在不同的虚拟机上），目前正在调查写入和读取操作期间的故障转移时间，以防其中一个节点死亡。 优雅地关闭一个节点时，故障转移时间非常好，但是，当杀死一个节点（通过关闭 VM）时，测试期间的延迟约为 12 秒。我猜这与 tcp 超时有关？
有什么办法可以调整吗？
编辑： 目前我们使用的是 Cassandra 版本 2.0.10。 我们正在使用 java 客户端驱动程序，版本 2.1.9.
更详细地描述一下情况：
write/read 操作使用 QUROUM 一致性级别执行，复制因子为 3。集群由 3 个节点 (c1,c2,c3) 组成，每个节点位于不同的主机上（虚拟机）。客户端驱动程序连接到 c1。在测试期间，我关闭了 c2 的主机。从那时起，我们观察到客户端阻塞了 > 12 秒，直到其他节点意识到 c2 消失了。所以我认为这不是客户端问题，因为客户端连接到节点 c1，在这种情况下它仍然是 运行。
编辑： 我不相信 VM 中的 运行 cassandra 会影响网络堆栈。事实上，终止 VM 的效果是 TCP 连接不会终止。在这种情况下，远程主机只能通过某种超时机制（应用程序级协议超时或 TCP 超时）注意到这一点。 如果进程在 OS 级别被杀死，OS 的 TCP 堆栈将负责终止 TCP 连接（恕我直言，TCP 重置），使远程主机能够立即收到有关失败的通知。 然而，重要的是，即使在主机因硬件故障而崩溃，或主机因网络电缆被拔出而断开连接的情况下（在这两种情况下，TCP 连接都不会立即终止），故障转移时间仍然是低的。我已经尝试 sigkill VM 中的 cassandra 进程。在这种情况下，故障转移时间约为 600 毫秒，这很好。
亲切的问候
Failover times are pretty good when shutting down one node gracefully, however, when killing a node (by shutting down the VM) the latency during the tests is about 12 seconds
12 秒是一个相当大的值。进一步调查前的一些问题
你的 Cassandra 版本是多少？自版本 2.0.2 以来，有一种推测重试机制有助于减少此类故障转移场景的延迟：http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2
您使用的客户端驱动程序是什么（java？c#？版本？）。通常使用正确配置的负载平衡策略，当节点关闭时，客户端将通过重新路由到另一个副本来自动重试查询。在驱动程序端也实现了推测性重试：http://datastax.github.io/java-driver/manual/speculative_execution/
编辑：对于要标记为关闭的节点，八卦协议正在使用 phi 应计检测器。该算法不具有二进制状态 (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
另一个问题是：您使用驱动程序的什么负载平衡策略？您是否使用了推测重试策略？