You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Evgeny Stanilovsky (Jira)" <ji...@apache.org> on 2025/02/18 12:35:00 UTC
[jira] [Updated] (IGNITE-24537) CPCC. Handle tableId changes
[ https://issues.apache.org/jira/browse/IGNITE-24537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evgeny Stanilovsky updated IGNITE-24537:
----------------------------------------
Description:
After store replication finished it need to trigger new catalog version and unlock new zone.
This catalog version fires event which switches affinity replication to the new zone only.
All tx started after new version activation time (T2) need to be replicated through affinity replicator.
After T2 we can decide that cpcc task is completed and proceed with further completion jobs: change global task state.
Additionally we can switch replication to the new affinity after all transactions which crossing T2 will be finished.
We need map like:
{newTableId -> {oldTableId1: tsSwitch1, oldTableId2: tsSwitch2}}
We need to support 2 cases here:
# Client send request with already new tableId but with historical timestamp
# Client pauses a bit and requests with oldTableId but current ts (after T2), seems this can be handled through server side response that new metadata is available.
[1] https://issues.apache.org/jira/browse/IGNITE-24530
was:
After store replication finished it need to trigger new catalog version and unlock new zone.
This catalog version fires event which switches affinity replication to the new zone only.
All tx after new version activation time (T2) need to be replicated through affinity replicator.
After T2 we can decide that cpcc task is completed and proceed with further completion jobs: change global task state.
Additionally we can switch replication to the new affinity after all transactions which crossing T2 will be finished.
We need map like:
{newTableId -> {oldTableId1: tsSwitch1, oldTableId2: tsSwitch2}}
We need to support 2 cases here:
# Client send request with already new tableId but with historical timestamp
# Client pauses a bit and requests with oldTableId but current ts (after T2), seems this can be handled through server side response that new metadata is available.
[1] https://issues.apache.org/jira/browse/IGNITE-24530
> CPCC. Handle tableId changes
> ----------------------------
>
> Key: IGNITE-24537
> URL: https://issues.apache.org/jira/browse/IGNITE-24537
> Project: Ignite
> Issue Type: Task
> Components: sql
> Affects Versions: 3.0
> Reporter: Evgeny Stanilovsky
> Priority: Major
> Labels: ignite-3
>
> After store replication finished it need to trigger new catalog version and unlock new zone.
> This catalog version fires event which switches affinity replication to the new zone only.
> All tx started after new version activation time (T2) need to be replicated through affinity replicator.
> After T2 we can decide that cpcc task is completed and proceed with further completion jobs: change global task state.
> Additionally we can switch replication to the new affinity after all transactions which crossing T2 will be finished.
> We need map like:
> {newTableId -> {oldTableId1: tsSwitch1, oldTableId2: tsSwitch2}}
> We need to support 2 cases here:
> # Client send request with already new tableId but with historical timestamp
> # Client pauses a bit and requests with oldTableId but current ts (after T2), seems this can be handled through server side response that new metadata is available.
> [1] https://issues.apache.org/jira/browse/IGNITE-24530
--
This message was sent by Atlassian Jira
(v8.20.10#820010)