我有一个从Cassandra读取数据的报告工具。配置是一致性级别是LOCAL_QUORUM，压缩策略是大小分层的，RF = 3。
当从报告工具向Cassandra提取请求时，根据Cassandra设计，它会触发读取修复以保证数据的一致性。这实际上是好的设计。但阅读修复费用昂贵，报告需要更长的时间。
我的报告用户仅在IST上午6点之后开始生成报告。是否有任何方法可以在用户开始使用报告之前安排读取修复。例如，我安排在上午6点之前完成阅读修理。因此，在早上6点之后IST，所有数据都将在整个群集中组成。
在这种情况下，一旦报告开始从Cassandra读取数据，它就不应该再次触发读取修复，因为我们刚刚将读取修复作为预定作业完成。我在上午6点IST发生后不一致的数据写入/更新很好。哪种技术可以安排读取修复，如果最近完成，我们确实避免了修复。 -Suyodha
答案 0 :(得分：1)
如果使用传统的反熵修复，则可以在一致性级别进行读取：ONE。
有许多方法可以进行反熵修复，最明显的是nodetool repair（可能是nodetool repair -par -inc或类似的命令行开关），或使用一些第三方工具修复小范围，例如由Brian Gallew维护的Cassandra Range Repair工具或Spotify's Cassandra Reaper。
答案 1 :(得分：1)
是什么让你认为阅读修理是什么减慢了它？检查（jmx）org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBackground和org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking以验证修复是否正在发生。如果数据在读取时不一致，那么只有在读取时才会启动读取修复。
如果确实存在问题，可以通过将机会设置为0来禁用对表的读取修复。
ALTER TABLE yourtable WITH read_repair_chance = 0;