简体繁体 English

在Cassandra中使用Hinted Handoff有什么意义，特别是对于一致性> ANY？

[英]What's the point of using Hinted Handoff in Cassandra, especially for consistency>ANY?

原文 2017-04-17 05:30:12 7 1 database/ cassandra/ replication/ consistency

In Cassandra, Hinted Handoff(HH) only happens when consistency level can be met. 在Cassandra中，Hinted Handoff（HH）仅在满足一致性级别时才会发生。 Also, hints are unreadable to clients. 此外，客户端无法读取提示。 With consistency level > ANY, using HH can improve neither write nor read availability. 在一致性级别> ANY的情况下，使用HH可以提高写入和读取可用性。 Requests still fail since the online replicas are insufficient to meet consistency requirements. 由于联机副本不足以满足一致性要求，因此请求仍然失败。
What's the point of using Hinted Handoff? 使用Hinted Handoff有什么意义？ Trading capacity for performance? 交易能力表现？ Why not just synchronize the failed-and-back node with other replica nodes (ie re-replication)? 为什么不将故障后节点与其他副本节点同步（即重新复制）？

1 个解决方案

Hinted handoff is just additional anti entropy measure. 暗示切换只是额外的反熵测量。 ie you don't have to run repairs right away and data gets consistent (if there was minor outage) when the node comes back online. 即，当节点重新联机时，您不必立即运行修复并且数据一致（如果有轻微中断）。

I guess it would just be too complicated to take take care of this with replication all the time because you would have to mark somehow the data that hasn't been replicated etc. Basically you would again have something similar to hinted handoff. 我想用复制一直处理这个问题太复杂了，因为你必须以某种方式标记未复制的数据等。基本上你会再次有类似于暗示切换的东西。

Some stuff from official docs: https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_about_hh_c.html#concept_ds_ifg_jqx_zj__extreme-write-availability 来自官方文档的一些内容： https ： //docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_about_hh_c.html#concept_ds_ifg_jqx_zj__extreme-write-availability

Basically it's to maximise write throughput of the cluster while there are minor outages. 基本上，它是在最小的中断时最大化群集的写入吞吐量。 It's configurable and you can disable it in case that you described when there are high consistency levels involved in both read and write. 它是可配置的，您可以在您描述读取和写入都涉及高一致性级别的情况下禁用它。

Plus you have to run the "re-replication" ie repair anyway. 另外，你必须运行“重新复制”即修复。 Because hinted handoff can't really take care of it all. 因为暗示切换不能真正处理这一切。

Personally I used them in a situation R-CL: ONE, W-CL: ONE, RF: 2, NODES: 3. They were very helpful because we maintained the write throughput while doing maintenance and rolling restarts on the cluster. 我个人在R-CL的情况下使用它们：ONE，W-CL：ONE，RF：2，NODES：3。它们非常有用，因为我们在群集上进行维护和滚动重启时保持了写入吞吐量。 So I would say it works well in situation where W-CL < RF. 所以我认为它在W-CL <RF的情况下运行良好。

Then again there is opinions like this one: 然后又有这样的意见：

https://blog.threatstack.com/scaling-cassandra-lessons-learned https://blog.threatstack.com/scaling-cassandra-lessons-learned

In fact, just disable them in the configuration. 实际上，只需在配置中禁用它们即可。 It's too easy to lose data during a prolonged outage or load spike, and if a node went down because of the load spike you're just going to pass the problem around the ring, eventually taking multiple or all nodes down. 在长时间停机或负载峰值期间丢失数据太容易了，并且如果节点由于负载峰值而出现故障，您只是将环绕问题传递出去，最终会使多个或所有节点关闭。 We never experienced this on Cassandra, but have on other systems that supported hinted handoffs. 我们从未在Cassandra上遇到这种情况，但是在支持暗示切换的其他系统上也有这种情况。