[
https://issues.apache.org/jira/browse/CASSANDRA-13441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972044#comment-15972044
]
Jeff Jirsa edited comment on CASSANDRA-13441 at 4/18/17 5:17 AM:
-----------------------------------------------------------------
Aleksey mentioned he had some concerns with the approach in IRC and, more
importantly, suggested a cleaner way to do it (rather than change the hashing,
write new system tables with fixed time stamps).
Using this method, we're able to actually push this to 3.0, 3.11, and trunk
without causing the ping-pong effect the original patch caused, and it's much
cleaner (doesn't go all the way down into the storage engine).
New patches here:
|| Branch || Testall || Dtest ||
| [3.0|https://github.com/jeffjirsa/cassandra/commits/cassandra-3.0-13441] |
[testall|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.0-13441]
|
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/16/]
|
| [3.11|https://github.com/jeffjirsa/cassandra/commits/cassandra-3.11-13441] |
[testall|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.11-13441]
|
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/17/]
|
| [trunk|https://github.com/jeffjirsa/cassandra/commits/cassandra-13441] |
[testall|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13441] |
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/18/]
|
(Unit and dtests are queued now but will likely take some time to complete)
was (Author: jjirsa):
Aleksey mentioned he had some concerns with the approach in IRC and, more
importantly, suggested a cleaner way to do it (rather than change the hashing,
write new system tables with fixed time stamps).
Using this method, we're able to actually push this to 3.0, 3.11, and trunk
without causing the ping-pong effect the original patch caused, and it's much
cleaner (doesn't go all the way down into the storage engine).
New patches here:
|| Branch || Testall || Dtest ||
| [3.0|https://github.com/jeffjirsa/cassandra/commits/cassandra-3.0-13441] |
[testall|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.0-13441]
|
[dtesthttps://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/16/|]
|
| [3.11|https://github.com/jeffjirsa/cassandra/commits/cassandra-3.11-13441] |
[testall|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.11-13441]
|
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/17/]
|
| [trunk|https://github.com/jeffjirsa/cassandra/commits/cassandra-13441] |
[testall|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13441] |
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/18/]
|
(Unit and dtests are queued now but will likely take some time to complete)
> Schema version changes for each upgraded node in a rolling upgrade, causing
> migration storms
> --------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-13441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13441
> Project: Cassandra
> Issue Type: Bug
> Components: Schema
> Reporter: Jeff Jirsa
> Assignee: Jeff Jirsa
> Fix For: 4.x
>
>
> In versions < 3.0, during a rolling upgrade (say 2.0 -> 2.1), the first node
> to upgrade to 2.1 would add the new tables, setting the new 2.1 version ID,
> and subsequently upgraded hosts would settle on that version.
> When a 3.0 node upgrades and writes its own new-in-3.0 system tables, it'll
> write the same tables that exist in the schema with brand new timestamps. As
> written, this will cause all nodes in the cluster to change schema (to the
> version with the newest timestamp). On a sufficiently large cluster with a
> non-trivial schema, this could cause (literally) millions of migration tasks
> to needlessly bounce across the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
