【发布时间】：2014-09-21 00:37:09
【问题描述】：
我们正在运行一个 DSE 3.2.2 集群，该集群启用了 cassandra 和 SolR，在虚拟机上的特定集群中运行了 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 索引已使用 SolR GUI 的完整重建索引触发器重建。
数据源表仍在使用“旧”压缩存储选项。
更新 #2
在最新的 cmets 之后，我不确定是否同时运行了进一步的插入。所以我确保推迟任何插入，运行 nodetool repair，完全重建索引。
查询似乎没问题！ 这似乎意味着在我上次尝试后不一致已经重新出现，并且是重建索引后一些插入的结果。我会尝试确认这会再次开始插入。
更新 #3 所以看起来事情又稳定了！升级似乎最初解决了这些问题，但由于我们在日志文件中发现的changed default transport from tcp to http 的问题，不一致仍然存在。两天前切换回http，修复并重新索引。所有插入，因为没有任何问题。谢谢您的帮助！稍后我会研究 tcpswitch。
【问题讨论】：
-
如果您使用 java 驱动程序插入数据，请确保检查您的 solrvalidation.log 是否有错误。还要检查您的 system.log 文件是否有任何索引错误。当通过 Cassandra 接口插入时，您不会从插入中得到 Solr 错误，因为索引是异步发生的。
-
所以回顾一下：1) 升级到 4.5.1。 2）修复所有节点并重新索引。 3) 没有 运行任何进一步的插入。然而，查询结果仍然不一致：是吗？