[ https://issues.apache.org/jira/browse/CASSANDRA-15398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969475#comment-16969475 ]
Aleksey Yeschenko commented on CASSANDRA-15398: ----------------------------------------------- 3.0: [code|https://github.com/iamaleksey/cassandra/commits/15398-3.0], [CI|https://circleci.com/workflow-run/67c87af7-3421-4e0e-8104-58bbb2bdfa67] 3.11: [code|https://github.com/iamaleksey/cassandra/commits/15398-3.11], [CI|https://circleci.com/workflow-run/8035e900-0589-46ad-88cf-cd64c6d2d2af] 4.0: [code|https://github.com/iamaleksey/cassandra/commits/15398-4.0], [CI|https://circleci.com/workflow-run/66c01c80-e97b-420a-b94b-598f8702d318] > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org