[
https://issues.apache.org/jira/browse/CASSANDRA-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Schuller updated CASSANDRA-3483:
--------------------------------------
Attachment: CASSANDRA-3483-trunk-refactored-v2.txt
{{CASSANDRA\-3483\-trunk\-refactored\-v2.txt}} I believe addresses the
concerns, plus makes other improvements. I'm much more happy with this one.
It addresses CASSANDRA-3807 by supporting fetch "consistency levels" (though
only ONE is currently usable without patching), and the filtering of hosts is
abstracted out.
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, though I think it's worthwhile doing
at some point separately.
The unit test is fixed; my adjustment of it was wrong because I wasn't picking
pending ranges (in the test).
I've tested both rebuild and bootstrap in a 3 node cluster.
I've added some more logging than what is typically the case; there have been
several cases where I wished streaming was logged in more detail at INFO,
particularly when bootstrapping or rebuilding. I think it's worthwhile to get
that in while at it.
> 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
> Affects Versions: 1.0.2
> Reporter: Chris Goffinet
> Assignee: Peter Schuller
> 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
