[
https://issues.apache.org/jira/browse/CASSANDRA-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196090#comment-13196090
]
Sylvain Lebresne commented on CASSANDRA-3483:
---------------------------------------------
bq. It addresses CASSANDRA-3807 by supporting fetch "consistency levels"
(though only ONE is currently usable without patching)
I think a first issue is that current bootstrap does not fail if no node is
alive for a given range, which arguably it should. I'm good with doing that,
though it would be worth backporting to 1.0 too so it may be worth splitting
that to a separate patch (or rather just create one for the fix in 1.0).
However, that does not solve the problem of bootstrap possibly breaking the
consistency contract. The problem being that if we transfer a range from a node
that happens to be lacking behind in term of consistency, and we end up
replacing a node that was not lacking behind, we could break some consistency
contracts. To fix that, I really only see only one solution right off the bat
(which doesn't mean there isn't other): it is to ensure that for each range, we
transfer it from (at least) the node we will replace for this range.
I believe the FetchConsistencyLevel of this patch is making an attempt to fix
this by allowing to fetch from more than one node. While it does make it less
likely to break consistency, unless we fetch from all nodes (and thus the one
we'll replace), we cannot be sure we won't break the consistency level for
people that say write at CL.ALL and read at CL.ONE. Overall, I fully agree this
is a problem that we should fix someone, but I'm not sure the
FetchConsistencyLevel is the right solution and even if it is it's a
complicated enough problem that it's worth it's own ticket. I would agree that
the problem with rebuild is a little bit different, but since anyway the patch
introduce FCL without using it, let's keep that for later if that's ok.
bq. There is still some duplication between Bootstrapper.bootstrap() and
StorageService.rebuild() in that both do the dance of iteration over tables to
construct the final map. I am not really feeling that abstracting away that is
a good idea to include in this ticket
I think it is, at least for a good chunk of it. It's not very complicated, it
clearly improves code readability and since the patch already refactor that
code I don't see a good reason to push that to later, especially if we agree
it's worthwhile.
Attaching a v3 that 1) remove FetchConsistencyLevel for the reasons above and
2) move most of the details of creating the multimaps in RangeStreamer.
> Support bringing up a new datacenter to existing cluster without repair
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3483
> Project: Cassandra
> Issue Type: Bug
> Reporter: Chris Goffinet
> Assignee: Peter Schuller
> Fix For: 1.1
>
> Attachments: CASSANDRA-3483-0.8-prelim.txt, CASSANDRA-3483-1.0.txt,
> CASSANDRA-3483-trunk-noredesign.txt, CASSANDRA-3483-trunk-rebase2.txt,
> CASSANDRA-3483-trunk-refactored-v1.txt, CASSANDRA-3483-trunk-refactored-v2.txt
>
>
> Was talking to Brandon in irc, and we ran into a case where we want to bring
> up a new DC to an existing cluster. He suggested from jbellis the way to do
> it currently was set strategy options of dc2:0, then add the nodes. After the
> nodes are up, change the RF of dc2, and run repair.
> I'd like to avoid a repair as it runs AES and is a bit more intense than how
> bootstrap works currently by just streaming ranges from the SSTables. Would
> it be possible to improve this functionality (adding a new DC to existing
> cluster) than the proposed method? We'd be happy to do a patch if we got some
> input on the best way to go about it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
