jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Mari (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-7234) Check for outdated journal at startup
Date Tue, 04 Dec 2018 16:28:00 GMT

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

Francesco Mari commented on OAK-7234:

My biggest concern about this issue is how we frame the problem. We want to make sure that
the journal is not outdated. But outdated with respect to what? We need a reference that conveys
information about the behaviour of the system before the failure and that would still work
in the face of restarts. The current timestamp at the time of startup is not a good reference
for many reasons.

I thought about comparing the timestamp of the last entry in the journal with the timestamp
of the most recent segment. I think it's safe to assume that the timestamp of the last entry
should never be older than the the most recent segment. If this is the case, we have some
segments that are not reachable by one of the head states pointed by the journal because the
journal points back in time.

But what happens if we recover a journal, and the last valid journal entry is older than the
most recent segment? Or if the last operation run on the system is a compaction that was interrupted
before it had a chance to clean after itself? The system will refuse to start up. I still
don't have a clear idea of how a solution for this problem would look like.

> Check for outdated journal at startup
> -------------------------------------
>                 Key: OAK-7234
>                 URL: https://issues.apache.org/jira/browse/OAK-7234
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segment-tar
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>            Priority: Minor
>              Labels: resilience, tooling
>             Fix For: 1.10
> To prevent accidentally branching the repository when the {{journal.log}} became outdated
(e.g. OAK-3702) we could add an additional safety feature which would prevent the repository
from starting in such cases. There's a couple of concerns to address:
>  * What kind of tooling / guidance do we need to provide to recover should such a situation
be detected?
>  * How do we detect the {{journal.log}} being outdated?
>  * How do we prevent false positives?
>  * How do we deal with situation where the {{journal.log}} modifications are intended
(e.g. by tools, of manual interventions)?

This message was sent by Atlassian JIRA

View raw message