We had six node clusters and when we attempted to join a node to this, cpu
load on two gradually climbed to abnormally high number. Stopping the
join and shutting down cassandra on two high-load nodes restored the
cluster health (we have RF=3)
Anyone have any insight on this cassandra behavior?
Duh. I totally forgot about my snapshotting just before daily rsync backup.
k.z.
On Wed, Nov 5, 2014 at 3:13 PM, Robert Coli wrote:
> On Wed, Nov 5, 2014 at 12:08 PM, KZ Win wrote:
>>
>> I have cassandra nodes with long uptime. Disk foot print for
>> cassandra data olde
I have cassandra nodes with long uptime. Disk foot print for
cassandra data older is different when I copy to a different folder.
Why is that ? I have used rsync and cp. This can be very confusing
when trying to do certain maintenance tasks like hardware upgrade on
EC2 and backing up a snapshot.
After joining a node to an existing cluster, I run 'nodetool cleanup'
as recommended on existing nodes in the cluster. On one node, after
some time, I am getting an error starting with
Exception in thread "main" java.lang.AssertionError:
[SSTableReader(path='/data/cassandra//Followers/-F
see what compactionstats is
> saying on all the nodes involved in the repair.
>
> source:
>
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Is-it-safe-to-stop-a-read-repair-and-any-suggestion-on-speeding-up-repairs-td6607367.html
>
>
> On Aug 1, 2014, at 2:4
I have a 2 node apache cassandra (2.0.3) cluster with rep factor of 1. I
change rep factor to 2 using the following command in cqlsh
ALTER KEYSPACE "mykeyspace" WITH REPLICATION = { 'class' :
'SimpleStrategy', 'replication_factor' : 2 };
I then tried to run recommended "nodetool repair" after d
