Thanks Eric for the reply.
On Thu, Oct 8, 2015 at 1:44 AM, Eric Stevens <migh...@gmail.com> wrote: > If you're at 1 node (N=1) and RF=1 now, and you want to go N=3 RF=3, you > ought to be able to increase RF to 3 before bootstrapping your new nodes, > with no downtime and no loss of data (even temporary). Effective RF is > min-bounded by N, so temporarily having RF > N ought to behave as RF = N. > > If you're starting at N > RF and you want to increase RF, things get harrier > if you can't afford temporary consistency issues. > We are ok with temporary consistency issues. Also, I was going through the following articles https://10kloc.wordpress.com/2012/12/27/cassandra-chapter-5-data-replication-strategies/ and following doubts came up in my mind :: a) Let's say at site-1, Application-Server (APP1) uses the two Cassandra-instances (CAS11 and CAS12), and APP1 generally uses CAS11 for all its needs (of course, whatever happens on CAS11, the same is replicated to CAS12 at Cassandra-level). Now, if CAS11 goes down, will it be the responsibility of APP1 to "detect" this and pick up CAS12 for its needs? Or some automatic Cassandra-magic will happen? b) In the same above scenario, let's say before CAS11 goes down, the amount of data in both CAS11 and CAS12 was "x". After CAS11 goes down, the data is being put in CAS12 only. After some time, CAS11 comes back up. Now, data in CAS11 is still "x", while data in CAS12 is "y" (obviously, "y" > "x"). Now, will the additional ("y" - "x") data be automatically put/replicated/whatever back in CAS11 through Cassandra? Or it has to be done manually? If there are easy recommended solutions to above, I am beginning to think that a 2*2 (2 nodes each at 2 data-centres) will be the ideal setup (allowing failures of entire site, or a few nodes on the same site). I am sorry for asking such newbie questions, and I will be grateful if these silly questions could be answered by the experts :) Thanks and Regards, Ajay
