[ 
https://issues.apache.org/jira/browse/CASSANDRA-15398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko updated CASSANDRA-15398:
------------------------------------------
          Fix Version/s:     (was: 3.11.x)
                             (was: 3.0.x)
                         3.11.6
                         3.0.20
          Since Version: 3.0.0
    Source Control Link: 
[7e878c1eb61b180227d6f1b70c4223e3ee71a754|https://github.com/apache/cassandra/commit/7e878c1eb61b180227d6f1b70c4223e3ee71a754]
             Resolution: Fixed
                 Status: Resolved  (was: Ready to Commit)

> 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: 3.0.20, 3.11.6, 4.0
>
>
> 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

Reply via email to