Mirza Aliev created IGNITE-24330:
------------------------------------

             Summary: 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


h3. Motivation
In [collocation|https://ggsystems.atlassian.net/issues/IGN-24435] 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.





--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to