Hi Sean, You got all valid points.
Please see my answers below - 1. Reason we want to move from 'A' to 'B' is to get rid of 'A' Azure region completely. 2. Cluster names in 'A' and 'B' are different. 3. DSbulk - Is there anyway I can do online migration? - I still need to get clarity on whether data for same keyspace/table names can be merged between A and B. So 2 cases - 1. If merge is not an issue - I guess DSBulk or SSTableloader would be an option? 2. If merge is an issue - I am guessing without app code change - this wont be possible ,right? *Thanks & Regards,* *Ankit Gadhiya* On Fri, Jan 17, 2020 at 9:40 AM Durity, Sean R <sean_r_dur...@homedepot.com> wrote: > A couple things to consider: > > - A separation of apps into their own clusters is typically a better > model to avoid later entanglements > - Dsbulk (1.4.1) is now available for only open source clusters. It is > a great tool for unloading/loading > - What data problem are you trying to solve with Cassandra and this > move to another cluster? If it is high-availability, then trying to get to > 2 DCs would be important. However, I think you will need at least a new > keyspace if you can’t combine the data from the clusters. Whether this > requires a code or config change depends on how configurable the developers > made the connection and query details. (As a side rant: why is it that > developers will write all kinds of new code, but don’t want to touch > existing code?) > - Your migration requirements are quite stringent (“we don’t want to > change anything, lose anything, or stop anything. Make it happen!”). There > may be a solution, but you may end up with something even more fragile > afterwards. I would push back to see what is negotiable. > > > > > > > > Sean Durity – Staff Systems Engineer, Cassandra > > > > *From:* Ankit Gadhiya <ankitgadh...@gmail.com> > *Sent:* Friday, January 17, 2020 8:50 AM > *To:* user@cassandra.apache.org > *Subject:* [EXTERNAL] Re: *URGENT* Migration across different Cassandra > cluster few having same keyspace/table names > > > > Hi Upasana, > > > > Thanks for your response. I’d love to do that as a first strategy but > since they are both separate clusters , how would I do that? Keyspaces > already have networktopologystrategy with RF=3. > > > > > > — Ankit > > > > On Fri, Jan 17, 2020 at 8:45 AM Upasana Sharma <028upasana...@gmail.com> > wrote: > > Hi, > > > > Did you consider adding Cassandra nodes from cluster B, into cluster A as > a different data center ? > > > > Your keyspace would than be on Network topology data strategy. > > > > In this case, all data can be synced between both data centers by > Cassandra using rebalancing. > > > > > > At client/application level you will have to ensure local quorum/ local > consistency so that there is no impact on latencies. > > > > Once you have moved data applications to new cluster , you can then remove > the old data center (cluster A), and cluster B would have fresh data. > > > > > > > > > > On Fri, Jan 17, 2020, 6:59 PM Ankit Gadhiya <ankitgadh...@gmail.com> > wrote: > > Thanks but there’s no DSE License. > > Wondering how sstableloader will help as some oh the Keyspace and tables > names are same. Also how do i sync few system keyspaces. > > > > > > Thanks & Regards, > > Ankit > > > > On Fri, Jan 17, 2020 at 1:11 AM Vova Shelgunov <vvs...@gmail.com> wrote: > > Loader* > > > > https://www.datastax.com/blog/2018/05/introducing-datastax-bulk-loader > [datastax.com] > <https://urldefense.com/v3/__https:/www.datastax.com/blog/2018/05/introducing-datastax-bulk-loader__;!!M-nmYVHPHQ!ZYeKjPXZF1wl9Nz0tJN8gy3m46Qf4nw7EmJX_Wd5ecuSBeP0V8GyjQhTiQh8hnDvcRk_RUg$> > > > > On Fri, Jan 17, 2020, 09:09 Vova Shelgunov <vvs...@gmail.com> wrote: > > DataStax bulk loaded can be an option if data is large. > > > > On Fri, Jan 17, 2020, 07:33 Nitan Kainth <nitankai...@gmail.com> wrote: > > If the keyspace already exist, use copy command or sstableloader to merge > data. If data volume it too big, consider spark or a custom java program > > > > Regards, > > Nitan > > Cell: 510 449 9629 > > > > On Jan 16, 2020, at 10:26 PM, Ankit Gadhiya <ankitgadh...@gmail.com> > wrote: > > > > Any leads on this ? > > > > — Ankit > > > > On Thu, Jan 16, 2020 at 8:51 PM Ankit Gadhiya <ankitgadh...@gmail.com> > wrote: > > Hi Arvinder, > > > > Thanks for your response. > > > > Yes - Cluster B already has some data. Tables/KS names are identical ; for > data - I still haven't got the clarity if it has identical data or no - I > am assuming no since it's for different customers but need the confirmation. > > > > *Thanks & Regards,* > > *Ankit Gadhiya* > > > > > > On Thu, Jan 16, 2020 at 8:49 PM Arvinder Dhillon <dhillona...@gmail.com> > wrote: > > So as I understand, Cluster B already has some data and not an empty > cluster. > > > > When you say, clusters share same keyspace and table names, do you mean > both clusters have identical data on those ks/tables? > > > > -Arvi > > > > On Thu, Jan 16, 2020, 5:27 PM Ankit Gadhiya <ankitgadh...@gmail.com> > wrote: > > Hello Group, > > > > I have a requirement in one of the production systems where I need to be > able to migrate entire dataset from Cluster A (Azure Region A) to Cluster B > (Azure Region B). > > > > Each cluster have 3 Cassandra nodes (RF=3) running used by different > applications. Few of the applications are common is Cluster A and Cluster B > thereby sharing same keyspace/table names. > > Need suggestion for the best possible migration strategy here considering > - 1. No Application code changes possible - Minor config/infra changes can > be considered. 2. Zero data loss. 3. No/Minimal downtime. > > > > It'd be great to hear ideas from all of you based on your experiences. > > > Cassandra Version - Cassandra 3.0.13 on both sides. > > Total Data size - Cluster A: 70 GB, Cluster B: 15 GB > > > > *Thanks & Regards,* > > *Ankit Gadhiya* > > -- > > *Thanks & Regards,* > > *Ankit Gadhiya* > > -- > > *Thanks & Regards,* > > *Ankit Gadhiya* > > -- > > *Thanks & Regards,* > > *Ankit Gadhiya* > > ------------------------------ > > The information in this Internet Email is confidential and may be legally > privileged. It is intended solely for the addressee. Access to this Email > by anyone else is unauthorized. If you are not the intended recipient, any > disclosure, copying, distribution or any action taken or omitted to be > taken in reliance on it, is prohibited and may be unlawful. When addressed > to our clients any opinions or advice contained in this Email are subject > to the terms and conditions expressed in any applicable governing The Home > Depot terms of business or client engagement letter. The Home Depot > disclaims all responsibility and liability for the accuracy and content of > this attachment and for any damages or losses arising from any > inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other > items of a destructive nature, which may be contained in this attachment > and shall not be liable for direct, indirect, consequential or special > damages in connection with this e-mail message or its attachment. >
