apache/cassandra · warning
Stop marker is older than start marker ({}<{}), so cannot as
Error message
Stop marker is older than start marker ({}<{}), so cannot assume we have a complete log of our votes in any consensus groups. Continuing to startup as configured. What it means
On Accord startup, the journal's stop marker is older than the start marker, so a complete log of votes cannot be assumed. Depending on stopMarkerFailurePolicy the node either exits, logs this warning and continues (unsafe startup), or rebootstraps.
Source
Thrown at src/java/org/apache/cassandra/service/accord/AccordService.java:553
{
if (state != State.INIT)
return;
boolean rebootstrap = false;
{
long startMarker = ReplayMarkers.readStartMarker();
long stopMarker = ReplayMarkers.readStopMarker();
if (stopMarker < startMarker)
{
switch (getAccord().journal.stopMarkerFailurePolicy)
{
default: throw new UnhandledEnum(getAccord().journal.stopMarkerFailurePolicy);
case EXIT:
throw new RuntimeException("Stop marker is older than start marker (" + stopMarker + '<' + startMarker + ") , so cannot assume we have a complete log of our votes in any consensus groups. Exiting.");
case ALLOW_UNSAFE_STARTUP:
case UNSAFE_STARTUP:
logger.warn("Stop marker is older than start marker ({}<{}), so cannot assume we have a complete log of our votes in any consensus groups. Continuing to startup as configured.", stopMarker, startMarker);
break;
case REBOOTSTRAP:
logger.info("Stop marker is older than start marker ({}<{}). Rebootstrapping.", stopMarker, startMarker);
rebootstrap = true;
}
}
}
logger.info("Starting background compaction of system_accord");
// We control this ourselves to ensure it starts when we need it, as especially commands_for_key
// can accumulate a lot of state and degrade replay performance significantly
scheduler.recurring(() -> {
CompactionManager.instance.submitBackground(AccordColumnFamilyStores.commandsForKey);
CompactionManager.instance.submitBackground(AccordColumnFamilyStores.journal);
}, 1L, MINUTES);
long durabilityFlushIntervalNanos = DatabaseDescriptor.getAccordDurabilityFlushInterval(NANOSECONDS);View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Prefer exiting (policy EXIT) and restoring a consistent journal/data directory
- If data loss is acceptable, intentionally allow unsafe startup via stopMarkerFailurePolicy
- Choose REBOOTSTRAP policy to rejoin the node with a clean Accord state
Example fix
// before accord.journal.stop_marker_failure_policy: ALLOW_UNSAFE_STARTUP // after accord.journal.stop_marker_failure_policy: REBOOTSTRAP
Defensive patterns
Strategy: validation
Validate before calling
// before starting, verify journal marker ordering from backups
if (stopMarker.compareTo(startMarker) < 0 && !allowUnsafe) throw new IllegalStateException("journal markers out of order; restore consistent backup"); Try / catch
catch (RuntimeException e) { /* choose EXIT/REBOOTSTRAP per stopMarkerFailurePolicy before continuing */ } Prevention
- Never restore older data-directory snapshots over newer journals
- Set stopMarkerFailurePolicy to EXIT or REBOOTSTRAP in production
- Use consistent, atomic backups of data + journal directories
When it happens
Trigger: localStartup reads start/stop markers from the Accord journal and finds stopMarker < startMarker (e.g. journal truncation, reverted/rolled-back data directory, restored backup).
Common situations: Restoring an older snapshot of the data directory over a newer journal; disk rollback after a crash; manual journal cleanup that removed newer segments; unsafe startup policy configured after failures.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- Stop marker is older than start marker ({stopMarker}<{startM
- Cannot reset state and replay from a save point; must modify
- Gave up waiting on journal index to be ready
- {} durability: refusing to report {} ({}): a failed update b
- accord.journal_directory must not be the same as the commitl
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/e716041277c4b75b.
Report an issue: GitHub.