cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius ┼Żaromskis (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-13441) Schema version changes for each upgraded node in a rolling upgrade, causing migration storms
Date Thu, 11 May 2017 15:23:04 GMT

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

Julius ┼Żaromskis edited comment on CASSANDRA-13441 at 5/11/17 3:22 PM:
-----------------------------------------------------------------------

Hi, any workaround for this issue? I've hit this after upgrading from 3.0.9 to 3.0.13 and
doing sstableupgrade. Noticed weird disk write patterns and started seeing migration tasks
bouncing around. I've only managed to update first of the 3 nodes. Migrations tasks have stopped
after I've rebooted first node.

{noformat}
Cluster Information:
        Name: cloud.zaromskis.lt cluster
        Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
        Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
        Schema versions:
                600b7268-d42a-3b72-8706-093b6c8cfaff: [10.240.0.6]
                77a40699-8e9e-35aa-834e-68c32e40a45a: [10.240.0.7, 10.240.0.8]
{noformat}

{noformat}
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                        
      Rack
UN  10.240.0.6  284.95 GB  256          63.4%             d0d83d9d-0dec-45cd-9ca9-93515fa131f3
 rack1
UN  10.240.0.7  288.53 GB  256          64.1%             6d9709a0-0e10-46a1-9afa-d106b74ca9e0
 rack1
UN  10.240.0.8  326.31 GB  256          72.5%             5c969700-8bd9-49a4-9772-1284439f8364
 rack1
{noformat}

The migrations are in fact executed, as I can see that on the disk, new files are created
every second in system keyspace. Why would cluster settle on the same schema version then?

The schema version of first node would not propagate to other nodes. I'm afraid further upgrades
might create new schema versions? I can't afford to lose any data. Any advise?




was (Author: juliuszaromskis):
Hi, any workaround for this issue? I've hit this after upgrading from 3.0.9 to 3.0.13 and
doing sstableupgrade. Noticed weird disk write patterns and started seeing migration tasks
bouncing around. I've only managed to update first of the 3 nodes. Migrations tasks have stopped
after I've rebooted first node.

{noformat}
Cluster Information:
        Name: cloud.zaromskis.lt cluster
        Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
        Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
        Schema versions:
                600b7268-d42a-3b72-8706-093b6c8cfaff: [10.240.0.6]
                77a40699-8e9e-35aa-834e-68c32e40a45a: [10.240.0.7, 10.240.0.8]
{noformat}

{noformat}
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                        
      Rack
UN  10.240.0.6  284.95 GB  256          63.4%             d0d83d9d-0dec-45cd-9ca9-93515fa131f3
 rack1
UN  10.240.0.7  288.53 GB  256          64.1%             6d9709a0-0e10-46a1-9afa-d106b74ca9e0
 rack1
UN  10.240.0.8  326.31 GB  256          72.5%             5c969700-8bd9-49a4-9772-1284439f8364
 rack1
{noformat}

The schema version of first node would not propagate to other nodes. I'm afraid further upgrades
might create new schema versions? I can't afford to lose any data. Any advise?

> 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: 3.0.14, 3.11.0, 4.0
>
>
> 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message