[
https://issues.apache.org/jira/browse/IGNITE-25861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-25861:
---------------------------------------
Description:
https://issues.apache.org/jira/browse/IGNITE-25671 was reverted. Updates to
table's stable assignments are processed sequentially, and raft node is stopped
only after corresponding partition is destroyed physically. This leads to
multiple checkpoints
Start / abort rebalance and clear partition methods wait for the partition to
be recreated, potentially causing similar problems
-Approach from GG8 should (to discuss) be used. Physical destruction of the
partition is scheduled for the next checkpoint. Creation of a partition waits
till previous destruction is competed-
Discussed with [~ibessonov] and [[email protected]], decided that we will
try to fix current approach. We won't force checkpoint after partitions
destruction, but will write only latest generation pages to compaction delta
file
was:
https://issues.apache.org/jira/browse/IGNITE-25671 was reverted. Updates to
table's stable assignments are processed sequentially, and raft node is stopped
only after corresponding partition is destroyed physically. This leads to
multiple checkpoints
Start / abort rebalance and clear partition methods wait for the partition to
be recreated, potentially causing similar problems
Approach from GG8 should (to discuss) be used. Physical destruction of the
partition is scheduled for the next checkpoint. Creation of a partition waits
till previous destruction is competed
> Fix checkpoint with different partition generations
> ---------------------------------------------------
>
> Key: IGNITE-25861
> URL: https://issues.apache.org/jira/browse/IGNITE-25861
> Project: Ignite
> Issue Type: Improvement
> Reporter: Philipp Shergalis
> Assignee: Philipp Shergalis
> Priority: Major
> Labels: ignite-3
>
> https://issues.apache.org/jira/browse/IGNITE-25671 was reverted. Updates to
> table's stable assignments are processed sequentially, and raft node is
> stopped only after corresponding partition is destroyed physically. This
> leads to multiple checkpoints
>
> Start / abort rebalance and clear partition methods wait for the partition to
> be recreated, potentially causing similar problems
>
> -Approach from GG8 should (to discuss) be used. Physical destruction of the
> partition is scheduled for the next checkpoint. Creation of a partition waits
> till previous destruction is competed-
> Discussed with [~ibessonov] and [[email protected]], decided that we
> will try to fix current approach. We won't force checkpoint after partitions
> destruction, but will write only latest generation pages to compaction delta
> file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
