cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kurt greaves <k...@instaclustr.com>
Subject Re: Migrate from one cluster of N nodes to another cluster of M nodes where N>M
Date Mon, 16 Oct 2017 20:43:46 GMT
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" <jean.jeancarl48@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 <kurt@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).
>>
>>
>

Mime
View raw message