[ 
https://issues.apache.org/jira/browse/IGNITE-24330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirza Aliev updated IGNITE-24330:
---------------------------------
    Description: 
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.

h3. Definition of Done

* DisasterRecoveryManager API is enriched with the methods to work with zones 
partitions 


  was:
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.




> 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
>            Priority: Major
>              Labels: ignite-3
>
> 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.
> 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)

Reply via email to