[
https://issues.apache.org/jira/browse/CASSANDRA-19190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-19190:
----------------------------------------
Fix Version/s: 5.1-alpha1
> ForceSnapshot transformations should not be persisted in the local log table
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-19190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19190
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
> Reporter: Marcus Eriksson
> Priority: Normal
> Fix For: 5.1-alpha1
>
>
> Per its inline comments, ForceSnapshot is a synthetic transformation whose
> purpose it to enable the local log to jump missing epochs. A common use for
> this is when replaying persisted events from the metadata log at startup. The
> log is initialised with {{Epoch.EMPTY}} but rather that replaying every
> single entry since the beginning of history, we select the most recent
> snapshot held locally and start the replay from that point. Likewise, when
> catching up from a peer, a node may receive a snapshot plus subsequent log
> entries. In order to bring local metadata to the same state as the snapshot,
> a {{ForceSnapshot}} with the same epoch as the snapshot is inserted into the
> {{LocalLog}} and enacted like any other other transformation. These synthetic
> transformations should not be persisted in the `system.local_metadata_log`,
> as they do not exist in the distributed metadata log. We _should_ persist the
> snapshot itself in `system.metadata_snapshots` so that we can avoid having to
> re-fetch remote snapshots (i.e. if a node were to restart shortly after
> receiving a catchup from a peer).
--
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
