Hi folks,
I have an interesting problem in Cassandra 1.1.2, a Google Search
wasn't much help, so I thought I'd ask here.
Essentially, I have a "problem keyspace" in my 2-node cluster that
keeps me from changing the replication factor on a specific keyspace.
It's probably easier to show what I'm seeing in cassandra-cli:
[default@foobar] update keyspace test1 with strategy_options =
{replication_factor:1};
2d5f0d16-bb4b-3d75-a084-911fe39f7629
Waiting for schema agreement...
... schemas agree across the cluster
[default@foobar] update keyspace test1 with strategy_options =
{replication_factor:1};
7745dd06-ee5d-3e74-8734-7cdc18871e67
Waiting for schema agreement...
... schemas agree across the cluster
Even though keyspace "test1" had a replication_factor of 1 to start
with, each of the above UPDATE KEYSPACE commands caused a new UUID to
be generated for the schema, which I assume is normal and expected.
Then I try it with the problem keyspace:
[default@foobar] update keyspace foobar with strategy_options =
{replication_factor:1};
7745dd06-ee5d-3e74-8734-7cdc18871e67
Waiting for schema agreement...
... schemas agree across the cluster
Note that the UUID did not change, and the replication_factor in the
underlying database did not change either.
The funny thing is that foobar had a replication_factor of 1
yesterday, then I brought my second node online and changed the
replication_factor to 2 without incident. I only ran into issues when
I tried changing it back to 1.
I tried running "nodetool clean" on both nodes, but the problem persists.
Any suggestions?
Thanks,
-- Doug
--
http://twitter.com/dmuth
