[
https://issues.apache.org/jira/browse/CASSANDRA-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149625#comment-16149625
]
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: https://issues.apache.org/jira/browse/CASSANDRA-5901
> 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
