al Gangakhedkar <kgangakhed...@gmail.com>
Reply-To: "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
;>
>>
>> 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
>> sstable-D. In
xist in the table directory and the
>> backups directory.
>>
>>
>>
>> So, that would be the difference between snapshots and backups.
>>
>>
>>
>> Best regards,
>>
>> -Razi
>>
>>
>>
>>
>>
>> *From: *Alai
tween snapshots and backups.
>
>
>
> Best regards,
>
> -Razi
>
>
>
>
>
> *From: *Alain RODRIGUEZ
> *Reply-To: *"user@cassandra.apache.org"
> *Date: *Thursday, January 12, 2017 at 9:16 AM
>
> *To: *"user@cassandra.apache.org"
>
between snapshots and backups.
Best regards,
-Razi
From: Alain RODRIGUEZ
Reply-To: "user@cassandra.apache.org"
Date: Thursday, January 12, 2017 at 9:16 AM
To: "user@cassandra.apache.org"
Subject: Re: Backups eating up disk space
My 2 cents,
As I mentioned earlier, we&#x
uot;
Date: Thursday, January 12, 2017 at 12:42 AM
To: "user@cassandra.apache.org"
Subject: Re: Backups eating up disk space
Hi Kunal,
Razi's post does give a very lucid description of how cassandra manages the
hard links inside the backup directory.
Where it needs clari
you 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 progressively
t; from 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/.
uot;
Date: Wednesday, January 11, 2017 at 6:47 AM
To: "user@cassandra.apache.org"
Subject: Re: Backups eating up disk space
Thanks for the reply, Razi.
As I mentioned earlier, we're not currently using snapshots - it's only the
backups that are bothering me right now.
So my next
vely used sstable files and directories. I think the *nodetool
> clearsnapshot* command is provided so that you don’t accidentally delete
> actively used files. Last I used *clearsnapshot*, (a very long time
> ago), I thought it left behind the directory, but this could have been
> fixe
ot;user@cassandra.apache.org"
Date: Tuesday, January 10, 2017 at 12:26 PM
To: "user@cassandra.apache.org"
Subject: Re: Backups eating up disk space
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 har
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 a
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 backups
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 the output of 'nodetool sta
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 the
15 matches
Mail list logo
