[ https://issues.apache.org/jira/browse/IGNITE-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686850#comment-16686850 ]
ASF GitHub Bot commented on IGNITE-10226: ----------------------------------------- GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/5396 IGNITE-10226 Fixed wrong partition state recovery You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10226 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5396.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5396 ---- commit 6fdc692458a63ea79bbfb5d554e6ec46ec8a2b90 Author: Pavel Kovalenko <jokserfn@...> Date: 2018-11-14T16:07:04Z IGNITE-10226 Partition shouldn't rewrite own state to WAL during crash recovery. commit d930bd6185cd0ccb01a9089cb5e384b1797bd36a Author: Pavel Kovalenko <jokserfn@...> Date: 2018-11-14T16:40:03Z IGNITE-10226 Partition should log to WAL current state on first update ---- > 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 > 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)