After there restart you what was in the logs for the 1.27 machine from the Migration.java logger ? Some of the messages will start with "Applying migration"
You should have shut down both of the nodes, then deleted the schema* and migration* system sstables, then restarted one of them and watched to see if it got to schema agreement. Cheers ----------------- Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com On 6 Aug 2011, at 22:56, Dikang Gu wrote: > 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 >
