You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (Jira)" <ji...@apache.org> on 2019/12/02 13:03:00 UTC
[jira] [Commented] (CASSANDRA-15398) Fix system_traces creation
timestamp; optimise system keyspace upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-15398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986035#comment-16986035 ]
Aleksey Yeschenko commented on CASSANDRA-15398:
-----------------------------------------------
Cheers, committed to 3.0 as [7e878c1eb61b180227d6f1b70c4223e3ee71a754|https://github.com/apache/cassandra/commit/7e878c1eb61b180227d6f1b70c4223e3ee71a754] and merged up.
> 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
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> 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