cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9749) CommitLogReplayer continues startup after encountering errors
Date Tue, 18 Aug 2015 09:57:46 GMT


Branimir Lambov commented on CASSANDRA-9749:

Let me try to rephrase and simplify Jonathan's question:

The original idea of this ticket was to let the commit log failure policy dictate what is
done in the case of replay failures. Now that CASSANDRA-8515 is in place, this means that
regardless of the failure policy the node will always refuse to start in the case of replay
failures (unless they are in the last section of the last segment). This can be overridded
using the {{cassandra.commitlog.ignorereplayerrors}} flag.

The question now is whether this is a good or sufficient solution, or should I invest time
to override the CASSANDRA-8515 override so that the original failure policy can apply?

My personal opinion is that it _is_ a proper solution. Any scenario I could imagine benefiting
from e.g. the 'stop' policy at log replay would also be better served by the same policy at
log startup.

> CommitLogReplayer continues startup after encountering errors
> -------------------------------------------------------------
>                 Key: CASSANDRA-9749
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Blake Eggleston
>            Assignee: Branimir Lambov
>             Fix For: 2.2.x
>         Attachments: 9749-coverage.tgz
> There are a few places where the commit log recovery method either skips sections or
just returns when it encounters errors.
> Specifically if it can't read the header here:
> Or if there are compressor problems here:
and here:
> Whether these are user-fixable or not, I think we should require more direct user intervention
(ie: fix what's wrong, or remove the bad file and restart) since we're basically losing data.

This message was sent by Atlassian JIRA

View raw message