I am sorry! This is true. I forgot "*not*"!
1. It's *not* recommended to use commit log after one node failure.
Cassandra has many options such as replication factor as
substitute solution.
*VafaTech.com - A Total Solution for Data Gathering & Analysis*
On Tue, Dec 3, 2019 at 10:42 AM Adarsh Kum
Thanks Hossein,
Just one more question is there any special SOP or consideration we have to
take for multi-site backup.
Please share any helpful link, blog or steps documented.
Regards,
Adarsh Kumar
On Sun, Dec 1, 2019 at 10:40 PM Hossein Ghiyasi Mehr
wrote:
> 1. It's recommended to use commi
1. It's recommended to use commit log after one node failure. Cassandra has
many options such as replication factor as substitute solution.
2. Yes, right.
*VafaTech.com - A Total Solution for Data Gathering & Analysis*
On Fri, Nov 29, 2019 at 9:33 AM Adarsh Kumar wrote:
> Thanks Ahu and Hussei
If you need backup for this environment, you should use snapshot and
incremental backups.
commit log backup solution depends on your environment and application.
For example you can use RAID 1 on commit log disk to be safe against
hardware failure.
*VafaTech.com - A Total Solution for Data Gatheri
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
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
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
for cassandra or datastax's documentation, commitlog's backup is not
mentioned.
only snapshot and incremental backup is described to do backup .
Though commitlog's archive for keyspace/table is not support but commitlog'
replay (though you must put log to commitlog_dir and restart the process)
sup
Thanks Guo and Eric for replying,
I have some confusions about commit log backup:
1. commit log archival technique is (
https://support.datastax.com/hc/en-us/articles/115001593706-Manual-Backup-and-Restore-with-Point-in-time-and-table-level-restore-
) as good as an incremental backup, a
For me, I think the last one :
Snapshot + Incremental + commitlog
is the most meaningful way to do backup and restore, when you make the data
backup to some where else like AWS S3.
- Snapshot based backup // for incremental data will not be backuped and
may lose data when restore to the tim
Hi,
TheLastPickle & Spotify have released Medusa as Cassandra Backup tool.
See :
https://thelastpickle.com/blog/2019/11/05/cassandra-medusa-backup-tool-is-open-source.html
Hope this link will help you.
Eric
Le 27/11/2019 à 08:10, Adarsh Kumar a écrit :
Hi,
I was looking for the backup st
Hi,
I was looking for the backup strategies of Cassandra. After some study I
came to know that there are the following options:
- Snapshot based backup
- Incremental backups
- Snapshot + incremental
- Snapshot + commitlog archival
- Snapshot + Incremental + commitlog
Which is the
13 matches
Mail list logo
