Re: Is this SSTable restore merging scenario possible ?

As said before, as long as you rename the UUIDs to match you should be good. The Production "win out" depends on the timestamps. In Cassandra last write wins, so as long as, for the same row, the production timestamps are more recent than the secondary cluster, the production data would "win

Re: Is this SSTable restore merging scenario possible ?

If its not on the same “cluster” and you are not using something like OpsCenter, the snapshotted files will have a diferent schema UUID for each entity. If you rename the files to have the matching UUID in the file names, then you should be able to do what you are talking about. On Mar 21,

Re: compaction stuck at 99.99%

only happens once in a while. i did check the logs for corrupted SSTable and didn’t find any. regards, -jerome On March 21, 2018 at 5:24:54 AM, shalom sagges (shalomsag...@gmail.com(mailto:shalomsag...@gmail.com)) wrote: > If the problem is recurring, then you might have a corrupted SSTable. >

Re: compaction stuck at 99.99%

If the problem is recurring, then you might have a corrupted SSTable. Check the system log. If a certain file is corrupted, you'll find it. grep -i corrupt /system.log* On Wed, Mar 21, 2018 at 2:18 PM, Jerome Basa wrote: > hi, > > when i run `nodetool compactionstats`

compaction stuck at 99.99%

hi, when i run `nodetool compactionstats` there’s this one compaction that’s stuck at 99.99% and the CPU load on the node is high compared to other nodes. i tried stopping the compaction but nothing happens. aside from restarting cassandra; what else can be done with this issue? thanks $

Is this SSTable restore merging scenario possible ?

Hi All, I am using Cassandra 3.10 I would like to know if the following SSTable row level merging scenario is possible: 1. On a Production Cluster - Take a full snapshot on every node 2. On a new, empty Secondary Cluster with the same topology - Create a matching schema (keyspaces + tables as