[CASSANDRA-19189] Revisit use of sealed period lookup tables

• Type: Improvement
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 5.1-alpha1
• Component/s: Transactional Cluster Metadata
• Epic Link: CEP-21: Follow Up
• Change Category: Code Clarity
• Complexity: Normal
• Platform: All

Source Control Link

https://github.com/apache/cassandra/commit/6ffd2677ee0d01c9e5493703a67255b0148106a4

Test and Documentation Plan

ci run

• Assignee: Marcus Eriksson
• Reporter: Marcus Eriksson

Authors

Marcus Eriksson

Reviewers

Alex Petrov, Sam Tunnicliffe

• Created: 11/Dec/23 13:57
• Updated: 09/Feb/24 14:53
• Resolved: 09/Feb/24 14:52

Description

Metadata snapshots are stored locally in the system.metadata_snapshots table, which is keyed by epoch. Snapshots are retrieved from this table for three purposes:

• to replay locally during startup
• to provide log state for a peer requesting catchup
• to create point-in-time ClusterMetadata, for disaster recovery

In the majority of cases, we always want to replay from the most recent snapshot so we can usually select the appropriate snapshot by simply scanning the snapshots table in reverse, which allows us to considerably simplify the process of looking up the desired snapshot. We will continue to persist historical snapshots, at least for now, so that we are able to select arbitrary snapshots should we want to reconstruct metadata state for arbitrary epochs.

Issue Links

• is duplicated by: CASSANDRA-19138 Flush sealed period/snapshot tables on every write
• links to: GitHub Pull Request #3088