[ https://issues.apache.org/jira/browse/CASSANDRA-19189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcus Eriksson updated CASSANDRA-19189: ---------------------------------------- Description: Metadata snapshots are stored locally in the {{system.metadata_snapshots}} table, which is keyed by epoch. Snapshots are retrieved from this table for two purposes: * to replay locally during startup * to provide log state for a peer requesting catchup 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. was:Metadata snapshots are stored locally in the {{system.metadata_snapshots}} table, which is keyed by epoch. Snapshots are retrieved from this table for two purposes:* to replay locally during startup* to provide log state for a peer requesting catchupIn 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. > 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 > Priority: Normal > Fix For: 5.1-alpha1 > > > Metadata snapshots are stored locally in the {{system.metadata_snapshots}} > table, which is keyed by epoch. Snapshots are retrieved from this table for > two purposes: > * to replay locally during startup > * to provide log state for a peer requesting catchup > 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