I have tried this, but the schema still does not agree in the cluster: [default@unknown] describe cluster; Cluster Information: Snitch: org.apache.cassandra.locator.SimpleSnitch Partitioner: org.apache.cassandra.dht.RandomPartitioner Schema versions: UNREACHABLE: [192.168.1.28] 75eece10-bf48-11e0-0000-4d205df954a7: [192.168.1.9, 192.168.1.25] 5a54ebd0-bd90-11e0-0000-9510c23fceff: [192.168.1.27]
Any other suggestions to solve this? Because I have some production data saved in the cassandra cluster, so I can not afford data lost... Thanks. On Fri, Aug 5, 2011 at 8:55 PM, Benoit Perroud <ben...@noisette.ch> wrote: > Based on http://wiki.apache.org/cassandra/FAQ#schema_disagreement, > 75eece10-bf48-11e0-0000-4d205df954a7 own the majority, so shutdown and > remove the schema* and migration* sstables from both 192.168.1.28 and > 192.168.1.27 > > > 2011/8/5 Dikang Gu <dikan...@gmail.com>: > > [default@unknown] describe cluster; > > Cluster Information: > > Snitch: org.apache.cassandra.locator.SimpleSnitch > > Partitioner: org.apache.cassandra.dht.RandomPartitioner > > Schema versions: > > 743fe590-bf48-11e0-0000-4d205df954a7: [192.168.1.28] > > 75eece10-bf48-11e0-0000-4d205df954a7: [192.168.1.9, 192.168.1.25] > > 06da9aa0-bda8-11e0-0000-9510c23fceff: [192.168.1.27] > > > > three different schema versions in the cluster... > > -- > > Dikang Gu > > 0086 - 18611140205 > > > -- Dikang Gu 0086 - 18611140205
