Just to completely eliminate the possibility of the same bug, if you look here:
http://www.mail-archive.com/dev@cassandra.apache.org/msg04992.html
If you create a test keyspace, and look at the timestamp in the
schema_keyspaces column family in comparison to your existing keyspace, is
that
It sounds plausible that is what we are running into. All of our nodes report a
replication factor of 2 (both using describe, and show schema), even though the
cluster reported that all schemas agree after I issued the change to 4.
If this is related to the bug that you filed, it might also
I was able to apply the patch in the cited bug report to the public source for
version 1.1.2. It seemed pretty straightforward; six lines in
MigrationManager.java were switched from System.currentTimeMillis() to
FBUtilities.timestampMicros(). I then re-built the project by running 'ant
We recently increased the replication factor of a keyspace in our cassandra
1.1.1 cluster from 2 to 4. This was done by setting the replication factor to 4
in cassandra-cli, and then running a repair on each node.
Everything seems to have worked; the commands completed successfully and disk
Do multiple nodes say the RF is 2 ? Can you show the output from the CLI ? Do
show schema and show keyspace say the same thing ?
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 13/07/2012, at 7:39 AM, Dustin Wenz wrote:
We recently
Possibly the bug with nanotime causing cassandra to think the change
happened in the past. Talked about onlist in past few days.
On Thursday, July 12, 2012, aaron morton aa...@thelastpickle.com wrote:
Do multiple nodes say the RF is 2 ? Can you show the output from the CLI
? Do show schema and
Sounds a lot like a bug that I hit that was filed and fixed recently:
https://issues.apache.org/jira/browse/CASSANDRA-4432
-Mike
On Jul 12, 2012, at 8:16 PM, Edward Capriolo wrote:
Possibly the bug with nanotime causing cassandra to think the change happened
in the past. Talked about onlist
