cassandra local_quorum 查询不一致
cassandra local_quorum query is inconsistent
卡桑德拉版本：2.1.15
节点数：dc1:80,dc2:80
问题：
我们的复制策略如下：
WITH REPLICATION = {'class':'NetworkTopologyStrategy','dc1': 3,'dc2': 3};
我们用Cassandra遇到问题，用local_quorum查询时不一致。我们只会在 dc1 中读写。
我们也是用local_quorum来写，然后用local_quorum来查询。
但是有一个现象，使用下面的语句：
select count from table where partitionKey=?
查询结果最初不一致，最终一致。
假设第一个是10000，第二个是9998，第三个是9997，最后可能还是10001（可能是触发读修复，导致最后稳定）。
这期间，我们做了大规模的扩张。并确保清理每台机器。而且我们还发现在不同的机器上使用getEndpoint的结果是不一致的。最后我们发现getEndpoint的结果有4台机器在dc1.
然后我们在对应的4台机器上执行getSstable，只有3台机器显示结果，另外一台机器没有显示结果。同时我们遇到了另一个partitionKey类似的问题，但是这个partitionKey只被查询了一次，因为我们在另外一个地方记录了partitionKey的总数，可以确认partitionKey的总数是不正确的。
我们把dc1的每台机器都一一重启后，这个问题就解决了。
partitionKey的总数和我们记录的结果是一致的，同一个查询多次，结果不会改变。
所以怀疑gossip同步节点信息太慢，可能导致选择节点查询时最终结果不一致
听起来这里可能发生了一些事情。我同意这可能是由于集群的扩展。
The results of the query were initially inconsistent and eventually consistent.
Cassandra 2.1 仍然允许每个 table 有一个配置的读取修复机会，默认值为 10%。因此，只要有足够的重试次数，就会触发读取修复，并且不一致的值会自行修复。
Then we executed getSstable on the corresponding 4 machines, only 3 machines showed the results, and the other machine did not show the results. At the same time, we encountered a similar problem with another partitionKey, but this partitionKey was only queried once, because we recorded the total number of partitionKey in another place, and we can confirm that the total number of partitionKey is incorrect.
不太确定那里发生了什么，但听起来一个或多个新节点难以加入，并且在令牌分配过程中可能出现了一些问题。我的猜测是一个或多个原始节点具有令牌范围映射（在 system.peers 中），这些映射不正确或与其他节点可以看到的内容不一致。很高兴知道重新启动后解决了这个问题。
建议：
- 升级。如果你不能离开 Cassandra 2.1，至少要上 2.1.19。它于去年 11 月发布，将有 2 年的错误修复，你现在没有。
- 建立你的节点数作为你的 RF 的一个因素。对于 3.0 之前的 Cassandra 版本，令牌分配有点古怪。为了帮助优化它，节点数量应该允许 RF 均匀平衡。在您的情况下，每个 DC 80 个节点 not 可以被 3（RF）整除。所以我会将每个 DC 提高到 81。然后 运行
cleanup，当然。
- 禁用动态告密。动态告密者利用八卦来尝试优化对性能更好的服务器的读取。但是，它会产生很多噪音，不幸的是，由于进行观察，这些噪音会减慢速度。它可能 是一个促成因素。只需设置
dynamic_snitch:false.
有关这些提示和其他信息的更多详细信息，我推荐两篇文章：
卡桑德拉版本：2.1.15
节点数：dc1:80,dc2:80
问题：
我们的复制策略如下：
WITH REPLICATION = {'class':'NetworkTopologyStrategy','dc1': 3,'dc2': 3};
我们用Cassandra遇到问题，用local_quorum查询时不一致。我们只会在 dc1 中读写。 我们也是用local_quorum来写，然后用local_quorum来查询。
但是有一个现象，使用下面的语句：
select count from table where partitionKey=?
查询结果最初不一致，最终一致。
假设第一个是10000，第二个是9998，第三个是9997，最后可能还是10001（可能是触发读修复，导致最后稳定）。 这期间，我们做了大规模的扩张。并确保清理每台机器。而且我们还发现在不同的机器上使用getEndpoint的结果是不一致的。最后我们发现getEndpoint的结果有4台机器在dc1.
然后我们在对应的4台机器上执行getSstable，只有3台机器显示结果，另外一台机器没有显示结果。同时我们遇到了另一个partitionKey类似的问题，但是这个partitionKey只被查询了一次，因为我们在另外一个地方记录了partitionKey的总数，可以确认partitionKey的总数是不正确的。
我们把dc1的每台机器都一一重启后，这个问题就解决了。 partitionKey的总数和我们记录的结果是一致的，同一个查询多次，结果不会改变。 所以怀疑gossip同步节点信息太慢，可能导致选择节点查询时最终结果不一致
听起来这里可能发生了一些事情。我同意这可能是由于集群的扩展。
The results of the query were initially inconsistent and eventually consistent.
Cassandra 2.1 仍然允许每个 table 有一个配置的读取修复机会，默认值为 10%。因此，只要有足够的重试次数，就会触发读取修复，并且不一致的值会自行修复。
Then we executed getSstable on the corresponding 4 machines, only 3 machines showed the results, and the other machine did not show the results. At the same time, we encountered a similar problem with another partitionKey, but this partitionKey was only queried once, because we recorded the total number of partitionKey in another place, and we can confirm that the total number of partitionKey is incorrect.
不太确定那里发生了什么，但听起来一个或多个新节点难以加入，并且在令牌分配过程中可能出现了一些问题。我的猜测是一个或多个原始节点具有令牌范围映射（在 system.peers 中），这些映射不正确或与其他节点可以看到的内容不一致。很高兴知道重新启动后解决了这个问题。
建议：
- 升级。如果你不能离开 Cassandra 2.1，至少要上 2.1.19。它于去年 11 月发布，将有 2 年的错误修复，你现在没有。
- 建立你的节点数作为你的 RF 的一个因素。对于 3.0 之前的 Cassandra 版本，令牌分配有点古怪。为了帮助优化它，节点数量应该允许 RF 均匀平衡。在您的情况下，每个 DC 80 个节点 not 可以被 3（RF）整除。所以我会将每个 DC 提高到 81。然后 运行
cleanup，当然。 - 禁用动态告密。动态告密者利用八卦来尝试优化对性能更好的服务器的读取。但是，它会产生很多噪音，不幸的是，由于进行观察，这些噪音会减慢速度。它可能 是一个促成因素。只需设置
dynamic_snitch:false.
有关这些提示和其他信息的更多详细信息，我推荐两篇文章：