[
https://issues.apache.org/jira/browse/IGNITE-24330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov resolved IGNITE-24330.
------------------------------------
Resolution: Fixed
> Revise DisasterRecoveryManager API in alignment with Colocation track
> ---------------------------------------------------------------------
>
> Key: IGNITE-24330
> URL: https://issues.apache.org/jira/browse/IGNITE-24330
> Project: Ignite
> Issue Type: Improvement
> Reporter: Mirza Aliev
> Assignee: Kirill Sizov
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In [collocation|https://issues.apache.org/jira/browse/IGNITE-22115] track we
> change the way how partitions are aligned with tables, so partitions will be
> the part of zones and tables in one zone will share common partitions from a
> zone.
> Currently, the DisasterRecoveryManager API for reset/restart partition
> operations is based on the assumption that partitions are tied to table
> entities.
> Example of {{resetPartitions}} method description:
> {code:java}
> * @param zoneName Name of the distribution zone. Case-sensitive, without
> quotes.
> * @param schemaName Schema name. Case-sensitive, without quotes.
> * @param tableName Table name. Case-sensitive, without quotes.
> * @param partitionIds IDs of partitions to reset. If empty, reset all
> zone's partitions.
> ....
> */
> private CompletableFuture<Void> resetPartitions(
> String zoneName,
> String schemaName,
> String tableName,
> Set<Integer> partitionIds,
> ...
> ) {
> {code}
> Problems with the current API:
> * The current API assumes partitions are part of a specific table, making it
> unclear how to handle partition resets in the new colocation model.
> * Users don't want to affect partition distribution across all tables in a
> zone when specifying a reset for a particular table.
>
> We need to provide a way to use the DisasterRecoveryManager API in a way that
> reflects the new colocation model, where partitions belong to zones rather
> than being tied to individual tables.
> As a solution, we could introduce a revised DisasterRecoveryManagerV2 API
> that removes direct table references and operates at the zone level. Once the
> colocation track is completed, we can switch to DisasterRecoveryManagerV2 and
> deprecate the existing implementation. However, it is still unclear which
> methods will be required and how they will impact table distribution.
> h3. Definition of Done
> * DisasterRecoveryManager API is enriched with the methods to work with zones
> partitions
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
