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
>>>
>>> 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*

Reply via email to