我们正在运行一个启用了cassandra和SolR的DSE 3.2.2群集，3个节点以及虚拟机上该特定群集中的复制因子2。
使用具有默认一致性级别（最近更改为仲裁）的Java客户端将数据直接写入c *。
问题在于，查询索引时发现的文档数量差异很大。因此，对某些数值使用stats组件也会产生不一致的结果。
如果当前没有写入数据，情况也是如此。我已经手动触发了该列族的nodetool修复，这触发了二级索引的重新索引（花了大约5-6个小时）。之后，结果仍然不一致。
在我们的用例中，过时几秒的数据不是问题，因此the workaround via session stickyness并没有为我解决问题。问题是数据在数天之后仍然不一致。
接下来，complete re-index with wiping the data位于列表中，但需要一些时间才能完成。
更新：我将升级到最新版本的C *和DSE，然后运行修复，然后运行重新索引并尽快报告（至少几天），而不是擦除和重新索引
非常感谢任何有关查询不一致的建议或共享经验！
更新＃1
查询结果仍然不一致。每个节点似乎都为我的查询返回了不同数量的文档。 集群已升级到4.5.1，sstables已升级，已执行修复，并且已使用SolR GUI的完整重新索引触发器重建整个SolR索引。
数据源表仍在使用＆＃34; old＆＃34;紧凑型存储选项。
更新＃2
在最新评论之后，我不确定是否还有其他插入。所以我确保阻止任何插入，运行nodetool修复，完成索引的重建。
查询似乎没问题！ 这似乎意味着在我上次尝试之后已经重新出现了不一致，并且是在重建索引之后的一些插入的结果。我将尝试确认这是再次启动插入。
更新＃3 所以看起来事情再次稳定！升级似乎最初解决了问题，但是由于我们在日志文件中发现changed default transport from tcp to http的问题，仍然存在不一致的问题。两天前切换回http，修复并重新编制索引。所有插入都没有任何问题。谢谢您的帮助！我将在稍后查看tcp＆lt; - ＆gt;开关。
答案 0 :(得分：4)
长期指数的不一致主要是由于＃＆＃34;掉落的突变和＃34;在Cassandra节点上：当向客户端正确确认写入时会发生这种情况，因为满足了所需的CL，但是某些节点在CL＆＃34;之外。实际上并没有写它，这意味着它们也没有对它进行索引。
这种不一致性由Cassandra通过读取修复和暗示切换自动解决，但也可能需要手动修复节点;在任何情况下，重建索引都没有帮助，因为不一致性首先在数据库级别。
从3.2.5开始的DSE版本应该包含一个Cassandra错误修复程序，可以大大减少掉落的突变：https://issues.apache.org/jira/browse/CASSANDRA-6510
请告知我们您的DSE版本，以及升级是否有帮助。
答案 1 :(得分：0)
4.x系列版本中已修复了诸如所述内容之类的偶然不一致。是否可以升级到新版本？