[
https://issues.apache.org/jira/browse/CASSANDRA-15398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15398:
------------------------------------------
Description:
We have introduced changes to system_traces tables in 3.0 (removal of
default_time_to_live, lowering of bloom_filter_fp_chance). We did not, however,
bump the timestamp with which we add the tables to schema, still defaulting to
0. As a result, for clusters that upgraded from 2.1/2.2, on bounce we would
always detect a mismatch between actual and desired table definitions, always
try to reconcile it by issuing migration tasks, but have them never override
the existing definitions in place.
Additionally, prior to 2.0.2 (CASSANDRA-6016) we’d use a ‘real’ timestamp, so
for clusters that started on even earlier versions of C* (say, 1.2), a bump to
the timestamp by 1 would be insufficient, and a larger generation is necessary
(I picked Jan 1 2020 as cut-off date).
The patch also optimises the process of upgrading replicated system tables.
Instead of issuing a migration task for every table that changed for every
node, we batch all changes into a single schema migration task.
> Fix system_traces creation timestamp; optimise system keyspace upgrades
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-15398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15398
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Priority: Normal
>
> We have introduced changes to system_traces tables in 3.0 (removal of
> default_time_to_live, lowering of bloom_filter_fp_chance). We did not,
> however, bump the timestamp with which we add the tables to schema, still
> defaulting to 0. As a result, for clusters that upgraded from 2.1/2.2, on
> bounce we would always detect a mismatch between actual and desired table
> definitions, always try to reconcile it by issuing migration tasks, but have
> them never override the existing definitions in place.
> Additionally, prior to 2.0.2 (CASSANDRA-6016) we’d use a ‘real’ timestamp, so
> for clusters that started on even earlier versions of C* (say, 1.2), a bump
> to the timestamp by 1 would be insufficient, and a larger generation is
> necessary (I picked Jan 1 2020 as cut-off date).
> The patch also optimises the process of upgrading replicated system tables.
> Instead of issuing a migration task for every table that changed for every
> node, we batch all changes into a single schema migration task.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
