Unfortunately, I don’t know much about the replication architecture. The only thing I know is that the replication is set at the keyspace level (i.e. 1, 2 or 3 or N replicas) and then there is the consistency level set at the client application level which determines how many acknowledgements are necessary to deem a write successful.
And you might have noticed in the video that anti-entropy is to be done as "deemed" necessary and not to be done blindly as a rule. E.g. if your data is read-only (never mutated) then there is no need for anti-entropy. From: eugene miretsky <eugene.miret...@gmail.com> Date: Thursday, April 20, 2017 at 5:52 PM To: Conversant <jthak...@conversantmedia.com> Cc: "user@cassandra.apache.org" <user@cassandra.apache.org> Subject: Re: Why are automatic anti-entropy repairs required when hinted hand-off is enabled? Thanks Jayesh, Watched all of those. Still not sure I fully get the theory behind it Aside from the 2 failure cases I mentioned earlier, the only other way data can become inconsistent is error when replicating the data in the background. Does Cassandra have a retry policy for internal replication? Is there a setting to change it? On Thu, Apr 6, 2017 at 10:54 PM, Thakrar, Jayesh <jthak...@conversantmedia.com<mailto:jthak...@conversantmedia.com>> wrote: I had asked a similar/related question - on how to carry out repair, etc and got some useful pointers. I would highly recommend the youtube video or the slideshare link below (both are for the same presentation). https://www.youtube.com/watch?v=1Sz_K8UID6E http://www.slideshare.net/DataStax/real-world-repairs-vinay-chella-netflix-cassandra-summit-2016 https://www.pythian.com/blog/effective-anti-entropy-repair-cassandra/ https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsRepair.html https://www.datastax.com/dev/blog/repair-in-cassandra From: eugene miretsky <eugene.miret...@gmail.com<mailto:eugene.miret...@gmail.com>> Date: Thursday, April 6, 2017 at 3:35 PM To: <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: Why are automatic anti-entropy repairs required when hinted hand-off is enabled? Hi, As I see it, if hinted handoff is enabled, the only time data can be inconsistent is when: 1. A node is down for longer than the max_hint_window 2. The coordinator node crushes before all the hints have been replayed Why is it still recommended to perform frequent automatic repairs, as well as enable read repair? Can't I just run a repair after one of the nodes is down? The only problem I see with this approach is a long repair job (instead of small incremental repairs). But other than that, are there any other issues/corner-cases? Cheers, Eugene