[
https://issues.apache.org/jira/browse/CASSANDRA-19190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19190:
----------------------------------------
Description: 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). (was: 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).)
> 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
