Thanks Julien. We ran repair. Increasing the RF should not make sstables
obselete. I can understand reducing RF or adding new node etc can result in
few obsolete sstables which eventually go away after you run cleanup.
On Wed, Dec 18, 2013 at 1:49 AM, Julien Campan wrote:
> Hi,
> When you are in
Thanks Aaron. No tmp files and not even a single exception in the
system.log.
If the file was last modified on 20-Nov then there must be an entry for
that in the log (either completed streaming or compacted).
On Tue, Dec 17, 2013 at 7:23 PM, Aaron Morton wrote:
> -tmp- files will sit in the dat
Hi,
When you are increasing the RF, you need to perform repair for the keyspace
on each node.(Because datas are not automaticaly streamed).
After that you should perform a cleanup on each node to remove obsolete
sstable.
Good luck :)
Julien Campan.
2013/12/18 Aaron Morton
> -tmp- file
-tmp- files will sit in the data dir, if there was an error creating them
during compaction or flushing to disk they will sit around until a restart.
Check the logs for errors to see if compaction was failing on something.
Cheers
-
Aaron Morton
New Zealand
@aaronmorton
Co-Foun
No snapshots.
I restarted the node and now the Load in ring is in sync with the disk
usage. Not sure what caused it to go out of sync. However, the Live SStable
count doesn't match exactly with the number of data files on disk.
I am going through the Cassandra code to understand what could be the
Do you have any snapshots on the nodes where you are seeing this issue?
Snapshots will link to sstables which will cause them not be deleted.
-Arindam
From: Narendra Sharma [mailto:narendra.sha...@gmail.com]
Sent: Sunday, December 15, 2013 1:15 PM
To: user@cassandra.apache.org
Subject: Cassandra
