[CASSANDRA-15398] Fix system_traces creation timestamp; optimise system keyspace upgrades

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 3.0.20, 3.11.6, 4.0-alpha3, 4.0
• Component/s: Cluster/Schema
• Bug Category: Code
• Severity: Low
• Complexity: Normal
• Discovered By: Code Inspection
• Platform: All
• Since Version: 3.0.0

Source Control Link

7e878c1eb61b180227d6f1b70c4223e3ee71a754

Test and Documentation Plan

Unit tests added

• Assignee: Aleksey Yeschenko
• Reporter: Aleksey Yeschenko

Authors

Aleksey Yeschenko

Reviewers

Sam Tunnicliffe

• Created: 05/Nov/19 14:24
• Updated: 15/May/20 08:38
• Resolved: 02/Dec/19 13:03

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.

Issue Links

• mentioned in: Page Loading...