在读取之前安排读取修复答案

【问题标题】：Schedule read repair before read在读取之前安排读取修复
【发布时间】：2016-12-05 09:57:37
【问题描述】：

我有一个从 Cassandra 读取数据的报告工具。配置是一致性级别是 LOCAL_QUORUM，压缩策略是大小分层的，RF=3。

当从报告工具向 Cassandra 发出拉取请求时，根据 Cassandra 的设计，它会触发读取修复以实现数据一致性。这实际上是一个很好的设计。但是读取修复很昂贵，而且报告需要更长的时间。

我的报告用户仅在 IST 早上 6 点之后才开始生成报告。有没有办法在用户开始使用报告之前安排读取修复。例如，我会在 IST 早上 6 点之前安排并完成读取修复。这样，在 IST 早上 6 点之后，所有数据都将跨集群组成。

在这种情况下，一旦报告开始从 Cassandra 读取数据，它不应再次触发读取修复，因为我们刚刚完成了读取修复作为计划作业。在 IST 早上 6 点发生后，我对不一致的数据写入/更新很好。哪种技术可以很好地安排读取修复，如果最近完成读取修复，我们真的会避免读取修复吗？ -Suyodha

【问题讨论】：

标签： cassandra datastax datastax-java-driver cassandra-2.1 spring-data-cassandra

【解决方案1】：

如果您使用传统的反熵修复，则可以在一致性级别进行读取：ONE。

进行反熵修复的方法有很多，最明显的是nodetool repair（可能带有nodetool repair -par -inc或类似的命令行开关），或者使用一些第三方工具修复小范围，例如Cassandra Range Repair 由 Brian Gallew 或 Spotify's Cassandra Reaper 维护的工具。

【讨论】：

嗨 Chris 和 Jeff..根据您的意见...我的问题已得到解答。谢谢你们。

【解决方案2】：

是什么让您认为读取修复会减慢速度？检查 (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;

【讨论】：

嗨 Chris 和 Jeff，感谢您的调查。我会尽快回复你们。非常感谢。
使用 ALTER TABLE 禁用读取修复只能防止后台读取修复，这是非阻塞的。前台读取修复只能通过使用较低的一致性级别来禁用。
没错，您需要 CL.ONE 和 read_repair_chance=0 来防止阻塞和后台读取修复。只做一个仍然会让另一个发生。我认为这仍然很可能不是报告需要很长时间的真正原因