[
https://issues.apache.org/jira/browse/IGNITE-22638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22638:
--------------------------------------
Description:
In general, before a checkpoint we temporarily store the calculated timestamp,
and after the checkpoint we publish that timestamp.
Once published, this timestamp can be used to calculate the MinimalRequiredTime
on the local node (this is out of current task scope, this task is only about
safe publication).
To publish this timestamp we need to add an additional {{flush(trigger=false)}}
method in {{MvPartitionStorage}} that will not immediately trigger flush, but
subscribe to the next flush
was:
To implement determination of the MinimalRequiredTime (IGNITE-22637), we need
to provide an API with semantics similar to CheckpointListener with two methods
beforeCheckpointBegin/afterCheckpointEnd.
This listener will be used to publish a timestamp that ensures that raft log
entries do not reference catalog history before that timestamp. This timestamp
should be introduced in IGNITE-22641.
In general, before a checkpoint we temporarily store the calculated timestamp,
and after the checkpoint we publish that timestamp. Once published, this
timestamp can be used to calculate the MinimalRequiredTime on the local node
(this is out of current task scope, this task is only about listener API).
This timestamp make sense only for "groups" with persistence, but it would be
nice to have a common API (for example in MvPartitionStorage). So the
implementation requires collaboration with the storage engine team.
> Catalog compaction. Add additional flush(trigger=false) method in
> MvPartitionStorage.
> -------------------------------------------------------------------------------------
>
> Key: IGNITE-22638
> URL: https://issues.apache.org/jira/browse/IGNITE-22638
> Project: Ignite
> Issue Type: Improvement
> Reporter: Pavel Pereslegin
> Assignee: Pavel Pereslegin
> Priority: Major
> Labels: ignite-3
>
> In general, before a checkpoint we temporarily store the calculated
> timestamp, and after the checkpoint we publish that timestamp.
> Once published, this timestamp can be used to calculate the
> MinimalRequiredTime on the local node (this is out of current task scope,
> this task is only about safe publication).
> To publish this timestamp we need to add an additional
> {{flush(trigger=false)}} method in {{MvPartitionStorage}} that will not
> immediately trigger flush, but subscribe to the next flush
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
