cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Eggleston (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5901) Bootstrap should also make the data consistent on the new node
Date Thu, 31 Aug 2017 21:24:00 GMT


Blake Eggleston commented on CASSANDRA-5901:

bq. say you have a RF=2 and a RF=3 keyspace, it would make sense to bootstrap the RF=2 at
ANY and the RF=3 one at QUORUM

Wouldn't bootstrap for a node be limited by the keyspace with the strictest consistency requirement
anyway though? It's not going to matter if the RF=2 / ANY keyspace was successful streaming
it's data if the RF=3 / QUORUM keyspace wasn't able to get it's data, bootstrap would fail
in that case. 

I suppose there is an argument to be made for clusters where only some of the keyspaces are
incrementally repaired. There would be a lot of overstreaming if there was a large keyspace
that you only did full repairs on... although I don't why anyone would run repairs like that.

> Bootstrap should also make the data consistent on the new node
> --------------------------------------------------------------
>                 Key: CASSANDRA-5901
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: sankalp kohli
>            Assignee: Marcus Eriksson
>            Priority: Minor
>             Fix For: 4.x
> Currently when we are bootstrapping a new node, it might bootstrap from a node which
does not have most upto date data. Because of this, we need to run a repair after that.
> Most people will always run the repair so it would help if we can provide a parameter
to bootstrap to run the repair once the bootstrap has finished. 
> It can also stop the node from responding to reads till repair has finished. This could
be another param as well. 

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message