Re: Query timeouts after Cassandra Migration
Thanks Eric. So do you advise copying tokens in such cases ? What procedure is advisable ? Latency increased on target cluster. I’d double check on storage disks but it should be same. — Ankit On Thu, Feb 6, 2020 at 9:07 PM Erick Ramirez wrote: > I didn’t copy tokens since it’s an identical cluster and we have RF as 3 >> on 3 node cluster. Is it still needed , why? >> > > In C*, same number of nodes alone isn't enough. Clusters aren't really > identical unless token assignments are the same. In your case though since > each node has a full copy of the data (RF = N nodes), they "appear" > identical. > > I recently migrated Cassandra keyspace data from one Azure cluster (3 >> Nodes) to another (3 nodes different region) using simple sstable copy. >> Post this , we are observing overall response time has increased and >> timeouts every 20 mins. >> > > You mean the response time on the source cluster increased? Or the > destination cluster? I can't see how the copy could affect latency unless > you're using premium storage disks and you've maxed out the throughput on > them. For example, P30 disks are capped at 200MB/s. > > Do I need to copy anything from system* > > > No, system tables are local to a node. Only ever copy the application > keyspaces. Cheers! > -- *Thanks & Regards,* *Ankit Gadhiya*
Re: Query timeouts after Cassandra Migration
Hi Michael, Thanks for your response. I didn’t copy tokens since it’s an identical cluster and we have RF as 3 on 3 node cluster. Is it still needed , why? Don’t see anything in cassandra log as such. I don’t have debugs enabled. Thanks & Regards, Ankit On Thu, Feb 6, 2020 at 1:47 PM Michael Shuler wrote: > Did you copy the tokens from cluster1 to new cluster2? Same Cassandra > version, same instance type/size? What to the logs say on cluster2 that > look different from the cluster1 norm? There are a number of possible > `nodetool` utilities that may help see what is happening on new cluster2. > > Michael > > On 2/6/20 8:09 AM, Ankit Gadhiya wrote: > > Hi Folks, > > > > I recently migrated Cassandra keyspace data from one Azure cluster (3 > > Nodes) to another (3 nodes different region) using simple sstable copy. > > Post this , we are observing overall response time has increased and > > timeouts every 20 mins. > > > > Has anyone faced such in their experiences ? > > Do I need to copy anything from system* > > Anything wrt statistics/cache ? > > > > Your time and responses on this are much appreciated. > > > > > > Thanks & Regards, > > Ankit > > -- > > *Thanks & Regards,* > > *Ankit Gadhiya* > > > > ----- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > > -- *Thanks & Regards,* *Ankit Gadhiya*
Query timeouts after Cassandra Migration
Hi Folks, I recently migrated Cassandra keyspace data from one Azure cluster (3 Nodes) to another (3 nodes different region) using simple sstable copy. Post this , we are observing overall response time has increased and timeouts every 20 mins. Has anyone faced such in their experiences ? Do I need to copy anything from system* Anything wrt statistics/cache ? Your time and responses on this are much appreciated. Thanks & Regards, Ankit -- *Thanks & Regards,* *Ankit Gadhiya*
Re: [EXTERNAL] Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names
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 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 > *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 > 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 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 wrote: > > DataStax bulk loaded can be an option if data is large. > > > > On Fri, Jan 17, 2020, 07:33 Nitan Kainth 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 > wrote: > > > > Any leads on this ? > > > > — Ankit > > > > On Thu, Jan 16, 2020 at 8:51 PM Ankit Gadhiya > 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 con
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 > 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 wrote: >> >>> Loader* >>> >>> https://www.datastax.com/blog/2018/05/introducing-datastax-bulk-loader >>> >>> On Fri, Jan 17, 2020, 09:09 Vova Shelgunov wrote: >>> >>>> DataStax bulk loaded can be an option if data is large. >>>> >>>> On Fri, Jan 17, 2020, 07:33 Nitan Kainth 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 >>>>> wrote: >>>>> >>>>> >>>>> Any leads on this ? >>>>> >>>>> — Ankit >>>>> >>>>> On Thu, Jan 16, 2020 at 8:51 PM Ankit Gadhiya >>>>> 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 >>>>>>> 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*
Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names
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 wrote: > Loader* > > https://www.datastax.com/blog/2018/05/introducing-datastax-bulk-loader > > On Fri, Jan 17, 2020, 09:09 Vova Shelgunov wrote: > >> DataStax bulk loaded can be an option if data is large. >> >> On Fri, Jan 17, 2020, 07:33 Nitan Kainth 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 >>> wrote: >>> >>> >>> Any leads on this ? >>> >>> — Ankit >>> >>> On Thu, Jan 16, 2020 at 8:51 PM Ankit Gadhiya >>> 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 >>>> 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 >>>>> 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*
Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names
Any leads on this ? — Ankit On Thu, Jan 16, 2020 at 8:51 PM Ankit Gadhiya 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 > 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 >> 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*
Re: *URGENT* Migration across different Cassandra cluster few having same keyspace/table names
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 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 > 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* >> >>
*URGENT* Migration across different Cassandra cluster few having same keyspace/table names
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*
Re: Keyspace Clone in Existing Cluster
Thanks Paul. This is interesting. So, anything I need to do after cp? - nodetool repair? Also I am assuming I need to be doing this exercise on all the nodes of the cluster - right? Any suggestion to automate this or do it just from a single node? — Ankit Gadhiya On Tue, Oct 29, 2019 at 11:21 PM Paul Carlucci wrote: > Straight up Unix cp command, make sure you're in the right directory. If > you try to use schema.cql then you're going to have to massage it somewhat > due to keyspace name differences and schema changes over time. You'll see > what I mean if you've got some. > > It goes without saying that you're gonna want to try this in non-prod > first. On a positive note you'll be learning some stuff they don't quite > teach in Datastax Academy! > > On Tue, Oct 29, 2019, 8:39 AM Ankit Gadhiya > wrote: > >> Thanks Paul. >> >> Copy SSTable - How? Using SSTableLoader or some other mechanism. >> >> >> *Thanks & Regards,* >> *Ankit Gadhiya* >> >> >> >> On Tue, Oct 29, 2019 at 11:36 AM Paul Carlucci >> wrote: >> >>> Copy the schema from your source keyspace to your new target keyspace, >>> nodetool snapshot on your source keyspace, copy the SSTable files over, do >>> a rolling bounce, repair, enjoy. In my experience a rolling bounce is >>> easier than a nodetool refresh. >>> >>> It's either that or just copy it with Spark. >>> >>> On Tue, Oct 29, 2019, 11:19 AM Ankit Gadhiya >>> wrote: >>> >>>> Thanks Alex. So How do I copy SSTables from 1.0 to 2.0? (Same >>>> SSTableLoader or any other approach?) >>>> Also since I've multi-node cluster - I'll have to do this on every >>>> single node - is there any tool or better way to execute this just from a >>>> single node? >>>> >>>> *Thanks & Regards,* >>>> *Ankit Gadhiya* >>>> >>>> >>>> >>>> On Tue, Oct 29, 2019 at 11:16 AM Alex Ott wrote: >>>> >>>>> You can create all tables in new keyspace, copy SSTables from 1.0 to >>>>> 2.0 tables & use nodetool refresh on tables in KS 2.0 to say Cassandra >>>>> about them. >>>>> >>>>> On Tue, Oct 29, 2019 at 4:10 PM Ankit Gadhiya >>>>> wrote: >>>>> >>>>>> Hello Folks, >>>>>> >>>>>> Greetings!. >>>>>> >>>>>> I've a requirement in my project to setup Blue-Green deployment for >>>>>> Cassandra. E.x. Say My current active schema (application pointing to) is >>>>>> Keyspace V1.0 and for my next release I want to setup Keysapce 2.0 (with >>>>>> some structural changes) and all testing/validation would happen on it >>>>>> and >>>>>> once successful , App would switch connection to keyspace 2.0 - This >>>>>> would >>>>>> be generic release deployment for our project. >>>>>> >>>>>> One of the approach we thought of would be to Create keyspace 2.0 as >>>>>> clone from Keyspace 1.0 including data using sstableloader but this would >>>>>> be time consuming, also being a multi-node cluster (6+6 in each DC) - it >>>>>> wouldn't be very feasible to do this manually on all the nodes for >>>>>> multiple >>>>>> tables part of that keyspace. Was wondering if we have any other creative >>>>>> way to suffice this requirement. >>>>>> >>>>>> Appreciate your time on this. >>>>>> >>>>>> >>>>>> *Thanks & Regards,* >>>>>> *Ankit Gadhiya* >>>>>> >>>>>> >>>>> >>>>> -- >>>>> With best wishes,Alex Ott >>>>> http://alexott.net/ >>>>> Twitter: alexott_en (English), alexott (Russian) >>>>> >>>> -- *Thanks & Regards,* *Ankit Gadhiya*
Re: Keyspace Clone in Existing Cluster
Thanks folks for your responses but still haven't found concrete solution for this. *Thanks & Regards,* *Ankit Gadhiya* On Tue, Oct 29, 2019 at 2:15 PM Sergio Bilello wrote: > Rolling bounce = Rolling repair per node? Would not it be easy to be > scheduled with Cassandra Reaper? > On 2019/10/29 15:35:42, Paul Carlucci wrote: > > Copy the schema from your source keyspace to your new target keyspace, > > nodetool snapshot on your source keyspace, copy the SSTable files over, > do > > a rolling bounce, repair, enjoy. In my experience a rolling bounce is > > easier than a nodetool refresh. > > > > It's either that or just copy it with Spark. > > > > On Tue, Oct 29, 2019, 11:19 AM Ankit Gadhiya > wrote: > > > > > Thanks Alex. So How do I copy SSTables from 1.0 to 2.0? (Same > > > SSTableLoader or any other approach?) > > > Also since I've multi-node cluster - I'll have to do this on every > single > > > node - is there any tool or better way to execute this just from a > single > > > node? > > > > > > *Thanks & Regards,* > > > *Ankit Gadhiya* > > > > > > > > > > > > On Tue, Oct 29, 2019 at 11:16 AM Alex Ott wrote: > > > > > >> You can create all tables in new keyspace, copy SSTables from 1.0 to > 2.0 > > >> tables & use nodetool refresh on tables in KS 2.0 to say Cassandra > about > > >> them. > > >> > > >> On Tue, Oct 29, 2019 at 4:10 PM Ankit Gadhiya > > > >> wrote: > > >> > > >>> Hello Folks, > > >>> > > >>> Greetings!. > > >>> > > >>> I've a requirement in my project to setup Blue-Green deployment for > > >>> Cassandra. E.x. Say My current active schema (application pointing > to) is > > >>> Keyspace V1.0 and for my next release I want to setup Keysapce 2.0 > (with > > >>> some structural changes) and all testing/validation would happen on > it and > > >>> once successful , App would switch connection to keyspace 2.0 - This > would > > >>> be generic release deployment for our project. > > >>> > > >>> One of the approach we thought of would be to Create keyspace 2.0 as > > >>> clone from Keyspace 1.0 including data using sstableloader but this > would > > >>> be time consuming, also being a multi-node cluster (6+6 in each DC) > - it > > >>> wouldn't be very feasible to do this manually on all the nodes for > multiple > > >>> tables part of that keyspace. Was wondering if we have any other > creative > > >>> way to suffice this requirement. > > >>> > > >>> Appreciate your time on this. > > >>> > > >>> > > >>> *Thanks & Regards,* > > >>> *Ankit Gadhiya* > > >>> > > >>> > > >> > > >> -- > > >> With best wishes,Alex Ott > > >> http://alexott.net/ > > >> Twitter: alexott_en (English), alexott (Russian) > > >> > > > > > > > - > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
Re: Keyspace Clone in Existing Cluster
Thanks Paul. Copy SSTable - How? Using SSTableLoader or some other mechanism. *Thanks & Regards,* *Ankit Gadhiya* On Tue, Oct 29, 2019 at 11:36 AM Paul Carlucci wrote: > Copy the schema from your source keyspace to your new target keyspace, > nodetool snapshot on your source keyspace, copy the SSTable files over, do > a rolling bounce, repair, enjoy. In my experience a rolling bounce is > easier than a nodetool refresh. > > It's either that or just copy it with Spark. > > On Tue, Oct 29, 2019, 11:19 AM Ankit Gadhiya > wrote: > >> Thanks Alex. So How do I copy SSTables from 1.0 to 2.0? (Same >> SSTableLoader or any other approach?) >> Also since I've multi-node cluster - I'll have to do this on every single >> node - is there any tool or better way to execute this just from a single >> node? >> >> *Thanks & Regards,* >> *Ankit Gadhiya* >> >> >> >> On Tue, Oct 29, 2019 at 11:16 AM Alex Ott wrote: >> >>> You can create all tables in new keyspace, copy SSTables from 1.0 to 2.0 >>> tables & use nodetool refresh on tables in KS 2.0 to say Cassandra about >>> them. >>> >>> On Tue, Oct 29, 2019 at 4:10 PM Ankit Gadhiya >>> wrote: >>> >>>> Hello Folks, >>>> >>>> Greetings!. >>>> >>>> I've a requirement in my project to setup Blue-Green deployment for >>>> Cassandra. E.x. Say My current active schema (application pointing to) is >>>> Keyspace V1.0 and for my next release I want to setup Keysapce 2.0 (with >>>> some structural changes) and all testing/validation would happen on it and >>>> once successful , App would switch connection to keyspace 2.0 - This would >>>> be generic release deployment for our project. >>>> >>>> One of the approach we thought of would be to Create keyspace 2.0 as >>>> clone from Keyspace 1.0 including data using sstableloader but this would >>>> be time consuming, also being a multi-node cluster (6+6 in each DC) - it >>>> wouldn't be very feasible to do this manually on all the nodes for multiple >>>> tables part of that keyspace. Was wondering if we have any other creative >>>> way to suffice this requirement. >>>> >>>> Appreciate your time on this. >>>> >>>> >>>> *Thanks & Regards,* >>>> *Ankit Gadhiya* >>>> >>>> >>> >>> -- >>> With best wishes,Alex Ott >>> http://alexott.net/ >>> Twitter: alexott_en (English), alexott (Russian) >>> >>
Re: Keyspace Clone in Existing Cluster
Thanks Alex. So How do I copy SSTables from 1.0 to 2.0? (Same SSTableLoader or any other approach?) Also since I've multi-node cluster - I'll have to do this on every single node - is there any tool or better way to execute this just from a single node? *Thanks & Regards,* *Ankit Gadhiya* On Tue, Oct 29, 2019 at 11:16 AM Alex Ott wrote: > You can create all tables in new keyspace, copy SSTables from 1.0 to 2.0 > tables & use nodetool refresh on tables in KS 2.0 to say Cassandra about > them. > > On Tue, Oct 29, 2019 at 4:10 PM Ankit Gadhiya > wrote: > >> Hello Folks, >> >> Greetings!. >> >> I've a requirement in my project to setup Blue-Green deployment for >> Cassandra. E.x. Say My current active schema (application pointing to) is >> Keyspace V1.0 and for my next release I want to setup Keysapce 2.0 (with >> some structural changes) and all testing/validation would happen on it and >> once successful , App would switch connection to keyspace 2.0 - This would >> be generic release deployment for our project. >> >> One of the approach we thought of would be to Create keyspace 2.0 as >> clone from Keyspace 1.0 including data using sstableloader but this would >> be time consuming, also being a multi-node cluster (6+6 in each DC) - it >> wouldn't be very feasible to do this manually on all the nodes for multiple >> tables part of that keyspace. Was wondering if we have any other creative >> way to suffice this requirement. >> >> Appreciate your time on this. >> >> >> *Thanks & Regards,* >> *Ankit Gadhiya* >> >> > > -- > With best wishes,Alex Ott > http://alexott.net/ > Twitter: alexott_en (English), alexott (Russian) >
Keyspace Clone in Existing Cluster
Hello Folks, Greetings!. I've a requirement in my project to setup Blue-Green deployment for Cassandra. E.x. Say My current active schema (application pointing to) is Keyspace V1.0 and for my next release I want to setup Keysapce 2.0 (with some structural changes) and all testing/validation would happen on it and once successful , App would switch connection to keyspace 2.0 - This would be generic release deployment for our project. One of the approach we thought of would be to Create keyspace 2.0 as clone from Keyspace 1.0 including data using sstableloader but this would be time consuming, also being a multi-node cluster (6+6 in each DC) - it wouldn't be very feasible to do this manually on all the nodes for multiple tables part of that keyspace. Was wondering if we have any other creative way to suffice this requirement. Appreciate your time on this. *Thanks & Regards,* *Ankit Gadhiya*
