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.