[
https://issues.apache.org/jira/browse/IGNITE-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16716696#comment-16716696
]
ASF GitHub Bot commented on IGNITE-10226:
-----------------------------------------
Github user Jokser closed the pull request at:
https://github.com/apache/ignite/pull/5368
> Partition may restore wrong MOVING state during crash recovery
> --------------------------------------------------------------
>
> Key: IGNITE-10226
> URL: https://issues.apache.org/jira/browse/IGNITE-10226
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Affects Versions: 2.4
> Reporter: Pavel Kovalenko
> Assignee: Pavel Kovalenko
> Priority: Major
> Fix For: 2.8
>
>
> The way to get it exists only in versions that don't have IGNITE-9420:
> 1) Start cache, upload some data to partitions, forceCheckpoint
> 2) Start uploading additional data. Kill node. Node should be killed with
> skipping last checkpoint, or during checkpoint mark phase.
> 3) Re-start node. The crash recovery process for partitions started. When we
> create partition during crash recovery (topology().forceCreatePartition()) we
> log it's initial state to WAL. If we have any logical update relates to
> partition we'll log wrong MOVING state to the end of current WAL. This state
> will be considered as last valid when we process PartitionMetaStateRecord
> record's during logical recovery. In "restorePartitionsState" phase this
> state will be chosen as final and the partition will change to MOVING, even
> in page memory it has OWNING or something else.
> To fix this problem in 2.4 - 2.7 versions, additional logging partition state
> change to WAL during crash recovery (logical recovery) should be removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
