[
https://issues.apache.org/jira/browse/CASSANDRA-19189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19189:
----------------------------------------
Source Control Link:
https://github.com/apache/cassandra/commit/6ffd2677ee0d01c9e5493703a67255b0148106a4
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Revisit use of sealed period lookup tables
> ------------------------------------------
>
> Key: CASSANDRA-19189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19189
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Priority: Normal
> Fix For: 5.1-alpha1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
