and backups.
Best regards,
-Razi
From: Alain RODRIGUEZ arodr...@gmail.com
Reply-To: "user@cassandra.apache.org" user@cassandra.apache.org
Date: Thursday, January 12, 2017 at 9:16 AM
To: "user@cassandra.apache.org" user@cassandra.apache.org
Subject: Re: Backups
regards,
>>
>> -Razi
>>
>>
>>
>>
>>
>> *From: *Alain RODRIGUEZ <arodr...@gmail.com>
>> *Reply-To: *"user@cassandra.apache.org" <user@cassandra.apache.org>
>> *Date: *Thursday, January 12, 2017 at 9:16 AM
>>
>> *To
sed.
>>
>>
>>
>> To drive the point home, …
>>
>> Suppose that you have another sstable-D that was either flushed from a
>> memtable or streamed from another node.
>>
>> At this point, in your main table directory, you will have sstable-C and
and backups.
>
>
>
> Best regards,
>
> -Razi
>
>
>
>
>
> *From: *Alain RODRIGUEZ <arodr...@gmail.com>
> *Reply-To: *"user@cassandra.apache.org" <user@cassandra.apache.org>
> *Date: *Thursday, January 12, 2017 at 9:16 AM
>
> *To: *&
"
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Date: Wednesday, January 11, 2017 at 6:47 AM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Subject: Re: Backup
"user@cassandra.apache.org" <user@cassandra.apache.org>
Date: Thursday, January 12, 2017 at 12:42 AM
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Subject: Re: Backups eating up disk space
Hi Kunal,
Razi's post does give a very lucid description of
will have a hardlink to
>> sstable-E. In your backups/ directory you will have hardlinks to sstable-A,
>> sstable-B and sstable-D.
>>
>>
>>
>> As you can see, the /backups directory quickly accumulates with all
>> un-compacted sstables and how it progressivel
om compaction, such as sstable-C and sstable-E.
>
> It is safe to delete the entire backups/ directory because all the data is
> represented in the compacted sstable-E.
>
> I hope this explanation was clear and gives you confidence in using rm to
> delete the directory for backups/.
>
"user@cassandra.apache.org" <user@cassandra.apache.org>
Date: Wednesday, January 11, 2017 at 6:47 AM
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Subject: Re: Backups eating up disk space
Thanks for the reply, Razi.
As I mentioned earlier, we're not currently us
rsions (so you might want to check that).
>
>
>
> HTH
>
> -Razi
>
>
>
>
>
> *From: *Jonathan Haddad <j...@jonhaddad.com>
> *Reply-To: *"user@cassandra.apache.org" <user@cassandra.apache.org>
> *Date: *Tuesday, January 10, 2017 at 12:26
.com>
Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Date: Tuesday, January 10, 2017 at 12:26 PM
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Subject: Re: Backups eating up disk space
If you remove the files from the backup direct
If you remove the files from the backup directory, you would not have data
loss in the case of a node going down. They're hard links to the same
files that are in your data directory, and are created when an sstable is
written to disk. At the time, they take up (almost) no space, so they
aren't
Thanks for quick reply, Jon.
But, what about in case of node/cluster going down? Would there be data
loss if I remove these files manually?
How is it typically managed in production setups?
What are the best-practices for the same?
Do people take snapshots on each node before removing the
You can just delete them off the filesystem (rm)
On Tue, Jan 10, 2017 at 8:02 AM Kunal Gangakhedkar
wrote:
> Hi all,
>
> We have a 3-node cassandra cluster with incremental backup set to true.
> Each node has 1TB data volume that stores cassandra data.
>
> The load in
Hi all,
We have a 3-node cassandra cluster with incremental backup set to true.
Each node has 1TB data volume that stores cassandra data.
The load in the output of 'nodetool status' comes up at around 260GB each
node.
All our keyspaces use replication factor = 3.
However, the df output shows
15 matches
Mail list logo