【发布时间】：2016-02-15 23:57:09
【问题描述】：
我有一个运行 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分钟），所有错误都消失了，我们的应用程序恢复正常。
有人可以解释一下这种行为，以及在我们实际升级“生产环境”时我们可以做些什么来避免这些错误（上述测试是在我们的测试环境中完成的）。
【问题讨论】：
标签： cassandra datastax datastax-java-driver paxos nosql