[
https://issues.apache.org/jira/browse/CASSANDRA-13441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972792#comment-15972792
]
Aleksey Yeschenko commented on CASSANDRA-13441:
-----------------------------------------------
The patches look good to me. +1
P.S. Thought initially that you overlooked specifying a 0 timestamp for
keyspace metadata itself (replication params and durable_writes), but
apparently there, in {{MigrationManager.maybeAddKeyspace()}} we already do
correctly set 0 timestamp. Makes me wonder how we forgot to do the same for
tables back then.
> 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)
