cassandra - 新节点加入群集

我有一个运行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：没有足够的副本可用于一致性SERIAL的查询（需要6个但只有5个活着）

我不确定

为什么当我的复制因子为3时，错误消息表明它需要6个节点。这是否意味着当数据从旧节点流向新节点时，现在由新节点拥有的范围，PAXOS将需要两个节点新旧节点将参与各种PAXOS阶段？
我的理解是，当新节点正在加入群集时，旧节点仍会获得所有客户端请求（对于现在由新节点拥有的令牌范围），但旧节点会将所有WRITE请求转发给新节点节点仍在提供READ请求。这对LWT和Paxos有何影响，因为CAS操作意味着READ和WRITE。因此，这可能是在进行任何CAS（IF NOT EXISTS）操作时需要6个节点响应的原因。即使是这种情况，为什么大多数CAS操作都失败了？当新节点正在加入时，LWT中是否存在可能的错误，或者新节点是否非常繁忙并且没有响应。在我的情况下，我确信新节点在处于JOINING状态时并不是非常繁忙，尽管LWT调用几乎整个时间都处于JOINING状态。

只要3个新节点中有2个加入群集，我们就会看到错误数量减少了很多，而且第3个节点也加入了（第1个节点需要大约5个小时才能加入，接下来10-20个小节点需要花费5个小时）分钟），所有错误都消失了，我们的申请恢复正常。

有人可以解释一下这种行为，以及当我们实际升级“生产环境”时，我们可以做些什么来避免这些错误（上述测试是在我们的测试环境中完成的）。