Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-15398

Fix system_traces creation timestamp; optimise system keyspace upgrades

    XMLWordPrintableJSON

    Details

    • Bug Category:
      Code
    • Severity:
      Low
    • Complexity:
      Normal
    • Discovered By:
      Code Inspection
    • Platform:
      All
    • Impacts:
      None
    • Since Version:
    • Test and Documentation Plan:
      Hide

      Unit tests added

      Show
      Unit tests added

      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.

        Attachments

          Activity

            People

            • Assignee:
              aleksey Aleksey Yeschenko
              Reporter:
              aleksey Aleksey Yeschenko
              Authors:
              Aleksey Yeschenko
              Reviewers:
              Sam Tunnicliffe
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: