[
https://issues.apache.org/jira/browse/CASSANDRA-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195533#comment-14195533
]
sankalp kohli commented on CASSANDRA-6862:
------------------------------------------
Say there are tombstones in the tables storing schema. They are all within GC
grace(written in last 7 days) and is successfully replicated on all machines.
You are upgrading a 1.2.19 cluster to 2.0.11. You upgrade one node to 2.0, the
2.0 node will compute the schema version without using tombstones. All 1.2
nodes are computing the schema version using tombstones. This will cause schema
disagreement leading to schema pulls. Even after schema pull, things won't
settle since schema versions will differ. This will happen till the entire
cluster is upgraded to 2.0.
For large clusters, this will be bad as it takes a long time to upgrade.
So this is the problem.
Also I think you are saying that 2.0 code will have a schema change and there
will be a schema disagreement after first node is upgraded. But that will
settle after all machines have the new schema.
In this, schema will bounce around till all machines have been upgraded.
> Schema versions mismatch on large ring
> --------------------------------------
>
> Key: CASSANDRA-6862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6862
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: 2.0
> Reporter: Oleg Anastasyev
> Assignee: Oleg Anastasyev
> Fix For: 2.0.7
>
> Attachments: 6862-v2.txt, SchemaVersionLiveColumns.txt
>
>
> We have a large cluster with several hundreds nodes in 1 ring. Sometimes,
> especially after massive restarts, schema versions reported on different
> nodes mismatch.
> Investigated and found, that difference is not in schema itsself, but in
> thombstones (different nodes have different set of thombstones applied to
> system tables).
> Fixed by digesting schema with thombstones removed first.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
