In my experience, I'd use two methods to make sure that you are covering your ass. 1. "old school" methodology would be to do the SStable load from old to new cluster -- if you do incremental snapshots, then you could technically minimize downtime and just load the latest increments with a little downtime. This is your fall back. 2. "new school" methodology would be to do all your insert/updates through event sourcing , in which you use the CQRS (command/query request segregation) which makes all updates into a series of commands, processed by a processor. If you have this architecture already, this means you have a durable message queue from which you can either a) replay all the mutations or b) do old school method 1 from above to get the bulk of the data, and then c) use a simultaneous processor for writing data to both old and new clusters.
Triggers can work, but it's super clugy in C* 2. Also, you don't have CDC in C* 2. Event sourcing + CQRS is the _literal_ best approach. Period. You can do a true blue / green test on both clusters (old and new) to see if your shit is consistent. Pardon the language, but you get the message. rahul.xavier.si...@gmail.com http://cassandra.link On Mon, Mar 25, 2019 at 7:31 PM Carl Mueller <carl.muel...@smartthings.com.invalid> wrote: > Either: > > double-write at the driver level from one of the apps and perform an > initial and a subsequent sstable loads (or whatever ETL method you want to > use) to merge the data with good assurances. > > use a trigger to replicate the writes, with some sstable loads / ETL. > > use change data capture with some sstable loads/ETL > > On Mon, Mar 25, 2019 at 5:48 PM Nick Hatfield <nick.hatfi...@metricly.com> > wrote: > >> Maybe others will have a different or better solution but, in my >> experience to accomplish HA we simply y write from our application to the >> new cluster. You then export the data from the old cluster using cql2json >> or any method you choose, to the new cluster. That will cover all live(now) >> data via y write, while supplying the old data from the copy you run. Once >> complete, set up a single reader that reads data from the new cluster and >> verify all is as expected! >> >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. >> *From: *Nandakishore Tokala >> *Sent: *Monday, March 25, 2019 18:39 >> *To: *user@cassandra.apache.org >> *Reply To: *user@cassandra.apache.org >> *Subject: *Merging two cluster's in to one without any downtime >> >> Please let me know the best practices to combine 2 different cluster's >> into one without having any downtime. >> >> Thanks & Regards, >> Nanda Kishore >> >
