Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "FAQ" page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/FAQ?action=diff&rev1=130&rev2=131 Comment: expand schema disgreement section to include causes * [[#jconsole_array_arg|Why can't I call jmx method X on jconsole? (ex. getNaturalEndpoints)]] * [[#max_key_size|What's the maximum key size permitted?]] * [[#ubuntu_hangs|I'm using Ubuntu with JNA, and holy crap weird things keep hanging and stalling and printing scary tracebacks in dmesg!]] - * [[#schema_disagreement|How do I fix schema disagreement errors?]] + * [[#schema_disagreement|What are schema disagreement errors and how do I fix them?]] * [[#dropped_messages|Why do I see "... messages dropped.." in the logs?]] <<Anchor(cant_listen_on_ip_any)>> @@ -500, +500 @@ If you have more information on the problem and better ways to avoid it, please do update this space. <<Anchor(schema_disagreement)>> - == How do I fix schema disagreement errors? == + == What are schema disagreement errors and how do I fix them? == + Cassandra schema updates [[LiveSchemaUpdates|assume that schema changes are done one-at-a-time]]. If you make multiple changes at the same time, you can cause some nodes to end up with a different schema, than others. (Before 0.7.6, this can also be caused by cluster system clocks being substantially out of sync with each other.) + + To fix schema disagreements, you need to force the disagreeing nodes to rebuild their schema. Here's how: + - Open the cassandra-cli and run: 'connect localhost/9160;', then 'describe cluster;'. + Open the cassandra-cli and run: 'connect localhost/9160;', then 'describe cluster;'. You'll see something like this: + {{{ + [default@unknown] describe cluster; + Cluster Information: + Snitch: org.apache.cassandra.locator.SimpleSnitch + Partitioner: org.apache.cassandra.dht.RandomPartitioner + Schema versions: + 75eece10-bf48-11e0-0000-4d205df954a7: [192.168.1.9, 192.168.1.25] + 5a54ebd0-bd90-11e0-0000-9510c23fceff: [192.168.1.27] + }}} + - Note which schemas are in the minority and mark down those IPs. Login to each of those machines and stop the Cassandra service/process by running 'sudo service cassandra stop' or 'kill <pid>'. Remove the schema* and migration* sstables inside of your /var/lib/cassandra/data/system folder (based on default settings). + Note which schemas are in the minority and mark down those IPs -- in the above example, 192.168.1.27. Login to each of those machines and stop the Cassandra service/process by running 'sudo service cassandra stop' or 'kill <pid>'. Remove the schema* and migration* sstables inside of your system keyspace (/var/lib/cassandra/data/system, if you're using the defaults). - After starting Cassandra again, your node will notice the missing information and pull in the correct data from the cluster. + After starting Cassandra again, this node will notice the missing information and pull in the correct schema from one of the other nodes. - To confirm everything is on the same schema, use the cassandra-cli to confirm 'describe cluster;' only returns one schema version. + To confirm everything is on the same schema, verify that 'describe cluster;' only returns one schema version. <<Anchor(dropped_messages)>> == Why do I see "... messages dropped.." in the logs? ==
