Migrate from one cluster of N nodes to another cluster of M nodes where N>M

[Jean Carlo <je...@gmail.com>]

Hello cassandra folks.

So I want to ask how to migrate a keyspace in production to another smaller
cluster without have a downtime service.

So I was thinking that I dont want to use sstableloader and paid for the
compactions and streaming. I want actually to use the procedure when both
clusters have the same numbers of nodes so I just need to make sure to have
the same token range repartition.

However my case is not the same. I will migrate for a cluster smaller than
in production and I was thinking that I could have the same token
repartition if I combine the tokens of diferents nodes.

If I can combine the tokens of differents machines, Do you see any problems
if I combine also the sstables of the same machines from the old cluster to
the new one ?

I think to combine the tokens I can use CCM to recreate my cluster in
production and then play with removenode.

For info, my keyspace is rf 3 and I have 3 racks


Best regards

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

Re: Migrate from one cluster of N nodes to another cluster of M nodes where N>M

[kurt greaves <ku...@instaclustr.com>]

you can change the cluster name, but it requires downtime. do you really
need a different cluster name?

On 16 Oct. 2017 11:17 pm, "Jean Carlo" <je...@gmail.com> wrote:

> Hi Kurt,
>
> Thanks for your answer. I was analysing this migration you said, and if I
> am not wrong, I wont be able to have two cluster independents.
>
> I wil try to explain this, as I can see, after the splits of DC's, I wont
> be able to change the name of the cluster, Am I right ? Even if I change
> the topology file (cassandra-topology.properties).
>
> Or it is possible ? That's why you mentioned (firewall rules are helpful
> here) isn't it?
>
>
>
>
> Saludos
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>
> On Mon, Oct 16, 2017 at 5:29 AM, kurt greaves <ku...@instaclustr.com>
> wrote:
>
>> If you create a new cluster and mimic the tokens across less nodes you
>> will still have downtime/missing data between the point when you copy all
>> the SSTables across and any new writes to the old cluster after you take
>> the copy.
>> Only way to really do this effectively is to do a DC migration. Brief run
>> through would be to:
>>
>>    1. Bring up a new DC (ensure you are using NetworkTopologyStrategy
>>    beforehand)
>>    2. Change your clients to only query the old DC (load balancing
>>    policy + local consistency levels)
>>    3. Replicate the keyspace across to the new DC
>>    4. Rebuild the nodes in the new DC from the old DC
>>    5. Run a repair
>>    6. Point clients at new DC
>>    7. Remove replication from old DC
>>    8. Split the DC's into two clusters (firewall rules are helpful here).
>>
>>
>

Re: Migrate from one cluster of N nodes to another cluster of M nodes where N>M

[Jean Carlo <je...@gmail.com>]

Hi Kurt,

Thanks for your answer. I was analysing this migration you said, and if I
am not wrong, I wont be able to have two cluster independents.

I wil try to explain this, as I can see, after the splits of DC's, I wont
be able to change the name of the cluster, Am I right ? Even if I change
the topology file (cassandra-topology.properties).

Or it is possible ? That's why you mentioned (firewall rules are helpful
here) isn't it?




Saludos

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

On Mon, Oct 16, 2017 at 5:29 AM, kurt greaves <ku...@instaclustr.com> wrote:

> If you create a new cluster and mimic the tokens across less nodes you
> will still have downtime/missing data between the point when you copy all
> the SSTables across and any new writes to the old cluster after you take
> the copy.
> Only way to really do this effectively is to do a DC migration. Brief run
> through would be to:
>
>    1. Bring up a new DC (ensure you are using NetworkTopologyStrategy
>    beforehand)
>    2. Change your clients to only query the old DC (load balancing policy
>    + local consistency levels)
>    3. Replicate the keyspace across to the new DC
>    4. Rebuild the nodes in the new DC from the old DC
>    5. Run a repair
>    6. Point clients at new DC
>    7. Remove replication from old DC
>    8. Split the DC's into two clusters (firewall rules are helpful here).
>
>

Re: Migrate from one cluster of N nodes to another cluster of M nodes where N>M

[kurt greaves <ku...@instaclustr.com>]

If you create a new cluster and mimic the tokens across less nodes you will
still have downtime/missing data between the point when you copy all the
SSTables across and any new writes to the old cluster after you take the
copy.
Only way to really do this effectively is to do a DC migration. Brief run
through would be to:

   1. Bring up a new DC (ensure you are using NetworkTopologyStrategy
   beforehand)
   2. Change your clients to only query the old DC (load balancing policy +
   local consistency levels)
   3. Replicate the keyspace across to the new DC
   4. Rebuild the nodes in the new DC from the old DC
   5. Run a repair
   6. Point clients at new DC
   7. Remove replication from old DC
   8. Split the DC's into two clusters (firewall rules are helpful here).