Same topology means the restore node should got the same tokes with the
backup nodes ;
ex : backup
node1(1/2/3/4/5) node2(6/7/8/9/10)
restore :
nodea(1/2/3/4/5) nodeb(6/7/8/9/10)
so node1's commitlog can be replay on nodea .
Adarsh Kumar 于2019年11月29日周五 下午2:03写道：
> Thanks Ahu and Hussein,
>
Thanks Ahu and Hussein,
So my understanding is:
1. Commit log backup is not documented for Apache Cassandra, hence not
standard. But can be used for restore on the same machine (For taking
backup from commit_log_dir). If used on other machine(s) has to be in the
same topology. Can it
Hi Enrico,
This is a classic chicken and egg problem with the
allocate_tokens_for_keyspace setting.
The allocate_tokens_for_keyspace setting uses the replication factor of a
DC keyspace to calculate the token allocation when a node is added to the
cluster for the first time.
Nodes need to be add
Hossein is right , But for use , we restore to the same cassandra topology
,So it is usable to do replay .But when restore to the
same machine it is also usable .
Using sstableloader cost too much time and more storage(though will reduce
after restored)
Hossein Ghiyasi Mehr 于2019年11月28日周四 下午7:40
Hi all,
I have an old datacenter with 4 nodes and 256 tokens each.
I am now starting a new datacenter with 3 nodes and num_token=4
and allocate_tokens_for_keyspace=myBiggestKeyspace in each node.
Both DCs run Cassandra 3.11.x.
myBiggestKeyspace has RF=3 in dcOld and RF=2 in dcNew. Now dcNew is ver
commitlog backup isn't usable in another machine.
Backup solution depends on what you want to do: periodic backup or backup
to restore on other machine?
Periodic backup is combine of snapshot and incremental backup. Remove
incremental backup after new snapshot.
Take backup to restore on other machi
