On Mon, Dec 30, 2013 at 6:45 AM, Tupshin Harper <tups...@tupshin.com> wrote:
> OK. Given the correction of my unfortunate partitioner error, you can, > and probably should, upgrade in place to 1.2, but with num_tokens=1 so it > will initially behave like 1.1 non vnodes would. Then you can do a rolling > conversion to more than one vnode per node, and once complete, shuffle your > vnodes. > @OP : 1) You should remove nodes, then upgrade in place to 1.2, then optionally convert to vnodes. Bootstrapping into a mixed version cluster is, if I understand correctly, not supported. 2) Depending on your data size and process used, using shuffle to convert to vnodes may fill your nodes/take forever/not work. [1] 3) I have not personally heard a single report of someone successfully using shuffle on a production cluster with real data. Try it on a representative data size in non-production first, and if you succeed, let the list know! :D If I were you, I would probably : a) question how much I really need vnodes on a 3 physical nodes per DC cluster b) if I decided I didn't really need vnodes, I would first decommission nodes 6 nodes down to 3 on 1.1 c) Then upgrade my 3 nodes to 1.2 via rolling restart d) Then use auto_bootstrap:false to upgrade instance hardware on the nodes by i) pre-copy data directory to target with rsync ii) configure target node with same initial_token as source node iii) drain and stop source node iv) re-copy data directory with rsync with --delete, to do final sync of data directories v) start new node with auto_bootstrap:false in conf file [2] =Rob [1] https://issues.apache.org/jira/browse/CASSANDRA-5525 [2] https://engineering.eventbrite.com/changing-the-ip-address-of-a-cassandra-node-with-auto_bootstrapfalse/
