cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (Jira)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-15398) Fix system_traces creation timestamp; optimise system keyspace upgrades
Date Thu, 07 Nov 2019 18:03:00 GMT

     [ 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message