You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Edward Capriolo (JIRA)" <ji...@apache.org> on 2012/10/21 16:16:12 UTC
[jira] [Created] (CASSANDRA-4843) When upgrading from 1.1.6 to 1.20
change in partitioner causes nodes not to start
Edward Capriolo created CASSANDRA-4843:
------------------------------------------
Summary: 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
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
[jira] [Commented] (CASSANDRA-4843) When upgrading from 1.1.6 to
1.20 change in partitioner causes nodes not to start
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481806#comment-13481806 ]
Jonathan Ellis commented on CASSANDRA-4843:
-------------------------------------------
bq. maybe it's time to change the behavior so that if a partitioner is saved in the system table, we use that
Partitioner is saved per-sstable so we can do this panic doublecheck, but you have to know (or think you know) the partitioner before you can actually open up a system table. I could be wrong, but I don't think it's a quick fix.
In the meantime, I've updated the comments and error message in 8f3d9b8371fa7c5dea83d45d83ec7fe4911a96c0.
> 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 beta 2
>
>
> 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
[jira] [Commented] (CASSANDRA-4843) When upgrading from 1.1.6 to
1.20 change in partitioner causes nodes not to start
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481241#comment-13481241 ]
Sylvain Lebresne commented on CASSANDRA-4843:
---------------------------------------------
bq. why are we changing the default?
The reason is that md5 is a bit cpu intensive and in some 2ndary index requests (that does a token computation for each key on disk it scans for internal reason that can't be changed easily) this was a bottleneck. The new default is the Murmur3Partitioner that is much cheaper to compute. Besides, for every query we do compute a bunch of token and vnodes will probably not reduce that, so it's a generic improvement.
That being said, I fully agree that the current upgrade experience is pretty harsh (even the NEWS file don't clearly explain the action to take to avoid this error). And since we save the partitonner and don't start if the user change it in the yaml, maybe it's time to change the behavior so that if a partitioner is saved in the system table, we use that (and log a warning if it differs from the yaml configured one).
> 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 beta 2
>
>
> 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
[jira] [Updated] (CASSANDRA-4843) When upgrading from 1.1.6 to 1.20
change in partitioner causes nodes not to start
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4843:
----------------------------------------
Fix Version/s: 1.2.0 beta 2
> 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 beta 2
>
>
> 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
[jira] [Updated] (CASSANDRA-4843) When upgrading from 1.1.6 to 1.20
change in partitioner causes nodes not to start
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-4843:
--------------------------------------
Attachment: 4843.txt
We missed the 1.1.7 window so I think it's pretty safe to guess that most 1.2 upgraders won't have any extra safety information we add to 1.1.8.
Patch attached to clarify the exception message.
> 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 rc1
>
> Attachments: 4843.txt
>
>
> 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
[jira] [Commented] (CASSANDRA-4843) When upgrading from 1.1.6 to
1.20 change in partitioner causes nodes not to start
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CASSANDRA-4843) When upgrading from 1.1.6 to
1.20 change in partitioner causes nodes not to start
Posted by "Edward Capriolo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480973#comment-13480973 ]
Edward Capriolo commented on CASSANDRA-4843:
--------------------------------------------
The error message is strange as well.
Changing paritioner on a existing cluster can cause data loose, Please verify your partitioner in cassandra.yaml
"Can cause data *loss" is impossible because Cassandra will not even start. If it did start it would definitely cause data loss.
> 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
>
> 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
[jira] [Commented] (CASSANDRA-4843) When upgrading from 1.1.6 to
1.20 change in partitioner causes nodes not to start
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504677#comment-13504677 ]
Sylvain Lebresne commented on CASSANDRA-4843:
---------------------------------------------
+1
> 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
> Assignee: Jonathan Ellis
> Fix For: 1.2.0 rc1
>
> Attachments: 4843.txt
>
>
> 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
[jira] [Commented] (CASSANDRA-4843) When upgrading from 1.1.6 to
1.20 change in partitioner causes nodes not to start
Posted by "Edward Capriolo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480974#comment-13480974 ]
Edward Capriolo commented on CASSANDRA-4843:
--------------------------------------------
Also the comments say,
{noformat}
# - RandomPartitioner distributes rows across the cluster evenly by md5.
# When in doubt, this is the best option.
{noformat}
If this is the best option why is another option chosen as the default?
> 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
>
> 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