You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Francesco Mari (JIRA)" <ji...@apache.org> on 2018/11/21 14:54:00 UTC

[jira] [Commented] (OAK-7866) Add tooling for recovering from an outdated journal

    [ https://issues.apache.org/jira/browse/OAK-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694803#comment-16694803 ] 

Francesco Mari commented on OAK-7866:
-------------------------------------

I committed a first implementation of the {{recover-journal}} command at r1847110. {{recover-journal}} backs the old journal up and generates a new journal from the information it extracts from the File Store. If anything goes wrong, {{recover-journal}} takes every possible step to roll back the old journal and to leave the File Store in a usable state.

I will implement a consistency check of the recovered journal next. In order to avoid code duplication between {{recover-journal}} and {{check}}, I'm going to refactor {{ConsistencyChecker}}. {{ConsistencyChecker}} already implements all the functionality I need but has three major shortcomings. First, it intermingles the logic with print statements. Second, it doesn't allow me to drive the check steps programmatically. Third, it prints its output on stdout instead of returning it in a form I can easily consume.

> Add tooling for recovering from an outdated journal
> ---------------------------------------------------
>
>                 Key: OAK-7866
>                 URL: https://issues.apache.org/jira/browse/OAK-7866
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: segment-tar
>            Reporter: Francesco Mari
>            Assignee: Francesco Mari
>            Priority: Major
>             Fix For: 1.10
>
>
> Some error conditions in the Segment Store might prevent the journal from being updated. After a restart the system will be rolled back to the latest version persisted in the journal. Every change performed after the system stopped updating the journal appears to be lost.
> Unless some deep inconsistencies are found in the segments, it might be possible to recover from an outdated journal by performing the following steps:
> * Backup the previous journal.
> * Scan the segments for node records representing super-roots.
> * Order the found records by segment creation date (ascending) and record number (ascending).
> * Create a new journal with the ordered entries.
> * Perform a sanity check of the journal (as the "check" tool does).
> We should have a tool executing these steps. Being a "porcelain" tool, it should have a small and stable command-line interface, be safe in the face of unexpected error conditions, and be friendly when communicating to the user both in case of success and in case of errors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)