Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 18 Apr 2017 02:20:42 +0000 (UTC)
From: "mck (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13063579.1492021414000.301839.1492482042116@Atlassian.JIRA>
In-Reply-To: <JIRA.13063579.1492021414000@Atlassian.JIRA>
References: <JIRA.13063579.1492021414000@Atlassian.JIRA> <JIRA.13063579.1492021414663@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13441) Schema version changes for
 each upgraded node in a rolling upgrade, causing migration storms
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 18 Apr 2017 02:20:47 -0000


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

mck commented on CASSANDRA-13441:
---------------------------------

{quote}Patch for trunk at: https://github.com/jeffjirsa/cassandra/tree/cassandra-13441{quote}

Did you push the branch [~jjirsa] ? (i can't see any such branch in your fork)

> 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)