[
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)
