[
https://issues.apache.org/jira/browse/IGNITE-23413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895644#comment-17895644
]
Ivan Bessonov edited comment on IGNITE-23413 at 11/12/24 11:22 AM:
-------------------------------------------------------------------
What I think needs to be done.
We should fix current local meta-storage version and use it for further reads.
Out of all timestamps that I mention further in the comment, we must choose the
minimal one.
* For zones that have pending or planned assignments, we should read them
locally, there's a timestamp stored in each individual assignment.
* For zones that only have stable assignments:
** Current implementation of data nodes timers uses "latest" catalog version
to determine the timestamp for future pending assignments. Until
https://issues.apache.org/jira/browse/IGNITE-22723 is not implemented, we
should do the same - be sure that latest catalog version is available. We can
use the timestamp of current meta-storage revision for that.
* For zones that have no assignments at all:
** This means that zone is either already deleted and assignments are dropped,
in which case we don't need to do anything.
** Or it means that we have not yet saved the initial stable assignments.
Let's imagine that.
• zone had been created on catalog version 10;
• zone had been updated on catalog version 12 (why not);
• current catalog version is 15, zone does exist in it.
In these circumstances, I propose returning the timestamp of catalog version
*11* - the latest available timestamp that has the "initial" zone parameters.
There is a possible side effect - if some code will try to read the revision
that corresponds to version 10, they would get a compaction exception. This
would mean that they would need to retry the read on oldest known revision - it
will still have the same version of distribution zone.
was (Author: ibessonov):
What I think needs to be done.
We should fix current local meta-storage version and use it for further reads.
Out of all timestamps that I mention further in the comment, we must choose the
minimal one.
* For zones that have pending or planned assignments, we should read them
locally, there's a timestamp stored in each individual assignment.
* For zones that only have stable assignments:
** Current implementation of data nodes timers uses "latest" catalog version
to determine the timestamp for future pending assignments. Until
https://issues.apache.org/jira/browse/IGNITE-22723 is not implemented, we
should do the same - be sure that latest catalog version is available. We can
use the timestamp of current meta-storage revision for that.
* For zones that have no assignments at all:
** This means that zone is either already deleted and assignments are dropped,
in which case we don't need to do anything.
** Or it means that we have not yet saved the initial stable assignments.
Let's imagine that.
• zone had been created on catalog version 10;
• zone had been updated on catalog version 12 (why not);
• current catalog version is 15, zone does exist in it.
In these circumstances, I propose returning the timestamp of catalog version
*11* - the latest available timestamp that has the "initial" zone parameters.
There is a possible side effect - if some code will try to read the revision
that corresponds to version 10, they would get a compaction exception. This
would mean that they would need to retry the read on oldest known revision - it
will still have the same version of distribution zone.
* If there are no pending and planned assignments, we might return the
timestamp that's associated with meta-storage revision.
> Catalog compaction. Component to determine minimum catalog version required
> by rebalance.
> -----------------------------------------------------------------------------------------
>
> Key: IGNITE-23413
> URL: https://issues.apache.org/jira/browse/IGNITE-23413
> Project: Ignite
> Issue Type: Improvement
> Reporter: Pavel Pereslegin
> Assignee: Ivan Bessonov
> Priority: Major
> Labels: ignite-3
>
> Each rebalance procedure uses specific catalog version, it "holds" the
> timestamp corresponding to the latest (at the moment of rebalancing start)
> version of the catalog
> To be able safely perform catalog compaction, we need to design and implement
> a component that can determine the minimum version required for active
> rebalances (to avoid deleting this version during compaction).
> {code:java}
> interface RebalanceMinimumRequiredTimeProvider {
> /**
> * Returns the minimum time required for rebalance,
> * or current timestamp if there are no active
> * rebalances and there is a guarantee that all rebalances
> * launched in the future will use catalog version
> * corresponding to the current time or greater.
> */
> long minimumRequiredTime();
> }
> {code}
> The component can be either global or local (whichever is easier to
> implement). This means that the compaction procedure can call the component
> on all nodes in the cluster and calculate the minimum.
> The component must be able to track rebalances that may be triggered during
> "replay" of the metastorage raft log.
> The component should return only monotonically increasing values.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
