我有一个运行 Cassandra 2.0.12（DataStax 社区版）的 9 节点集群。我不得不扩展这个集群，所以按照http://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_add_node_to_cluster_t.html建议的 DataStax 添加了 3 个节点
我们的应用程序利用了轻量级事务功能，我们发现虽然新节点处于 JOINING 状态（数据从旧节点流式传输到它们），但大多数涉及 LWT 的应用程序调用都因以下错误而失败
com.datastax.driver.core.exceptions.UnavailableException：没有足够的副本可用于一致性序列查询（需要 6 个但只有 5 个活着）
我不确定
为什么当我的复制因子为 3 时错误消息说它需要 6 个节点。这是否意味着当数据从旧节点流式传输到新节点现在由新节点拥有的范围时，PAXOS 将要求新旧节点都是参与各种 PAXOS 阶段？
我的理解是，当新节点加入集群时，旧节点仍会收到所有客户端请求（对于现在由新节点拥有的令牌范围），但旧节点会将所有 WRITE 请求转发给新节点，同时仍为 READ 请求提供服务. 这如何与 LWT 和 Paxos 一起工作，因为 CAS 操作意味着 READ 和 WRITE。那么这可能是在执行任何 CAS（如果不存在）操作时需要 6 个节点响应的原因吗？即使是这样，为什么大多数 CAS 操作都失败了？新节点加入时 LWT 是否可能存在错误，或者新节点非常繁忙且没有响应的事实。就我而言，我确信新节点在它们处于 JOINING 状态时并不是一直非常忙，尽管 LWT 调用在它们处于 JOINING 状态时几乎整个时间都失败了。
一旦 3 个新节点中的两个加入集群，我们可以看到错误数量大大减少，并且一旦第 3 个节点也加入（第一个节点加入大约需要 5 小时，然后其他节点在接下来的 10-20 分钟内加入），所有错误都消失了，我们的应用程序恢复正常。
有人可以解释一下这种行为，以及当我们实际升级“生产环境”时我们能做些什么来避免这些错误（上述测试是在我们的测试环境中完成的）。