Hi Paulo, thanks for your feedback, but I think this is not what I am looking for.
Starting with join_ring does not take any tokens in the ring. And the "nodetool join" afterwards will again do token-selection and data loading in one step. I would like to separate these steps: 1. assign tokens 2. have the node in a joining state, so that I can copy in data 3. mark the node as ready I just saw that perhaps write_survey could be misused for that. Did anyone ever use write_survey for such a partial bootstrapping? Do I have to worry about data-loss when using multiple write_survey nodes in one cluster? kind regards, Christian On Tue, Aug 4, 2015 at 2:24 PM, Paulo Motta <pauloricard...@gmail.com> wrote: > Hello Christian, > > You may use the start-up parameter -Dcassandra.join_ring=false if you > don't want the node to join the ring on startup. More about this parameter > here: > http://docs.datastax.com/en/cassandra/2.0/cassandra/tools/toolsCUtility_t.html > > You can later join the ring via nodetool join command: > http://docs.datastax.com/en/cassandra/2.0/cassandra/tools/toolsJoin.html > > auto_bootstrap=false is typically used to bootstrap new datacenters or > clusters, or nodes with data already on it before starting the process. > > Cheers, > > Paulo > > 2015-08-04 8:50 GMT-03:00 horschi <hors...@gmail.com>: > >> Hi everyone, >> >> I'll just ask my question as provocative as possible ;-) >> >> Isnt't auto_bootstrap=false broken the way it is currently implemented? >> >> What currently happens: >> New node starts with auto_bootstrap=false and it starts serving reads >> immediately without having any data. >> >> Would the following be more correct: >> - New node should stay in a joining state >> - Operator loads data (e.g. using nodetool rebuild or putting in >> backupped files or whatever) >> - Operator has to manually switch from joining into normal state using >> nodetool (only then it will start serving reads) >> >> Wouldn't this behaviour more consistent? >> >> kind regards, >> Christian >> > >
