Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 23 Oct 2012 06:21:12 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <1524126139.14783.1350973272341.JavaMail.jiratomcat@arcas>
In-Reply-To: <651373149.7298.1350828972121.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (CASSANDRA-4843) When upgrading from 1.1.6 to
 1.20 change in partitioner causes nodes not to start
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482149#comment-13482149 ] 

Sylvain Lebresne commented on CASSANDRA-4843:
---------------------------------------------

bq. but you have to know (or think you know) the partitioner before you can actually open up a system table

I don't think you do since the system table keyspace uses LocalStrategy (and this is hardcoded). That being said, even if we start saving the partitioner in the system table, it's possibly a little late for the upgrade to 1.2. I still think we should do it for 1.1.7 though (but to be clear, I'm all for keeping the panic doublecheck when we open a sstable because that protects again a different problem anyway).
                
> When upgrading from 1.1.6 to 1.20 change in partitioner causes nodes not to start
> ---------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-4843
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4843
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Edward Capriolo
>             Fix For: 1.2.0
>
>
> ERROR 10:17:20,341 Cannot open /home/edward/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-hf-1 because partitioner does not match org.apache.cassandra.dht.RandomPartitioner != org.apache.cassandra.dht.Murmur3Partitioner
> This is because 1.2 has a new default partitioner, why are we changing the default? Is this wise? The current partitioner has been rock solid for years. 
> Should the previously known partition be stored in the schema like the previously know seed nodes, and schema?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira