[
https://issues.apache.org/jira/browse/CASSANDRA-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143071#comment-14143071
]
Sam Tunnicliffe commented on CASSANDRA-6904:
--------------------------------------------
The reason I didn't add header checking during replay is I don't think it's
actually possible in 2.1.
CLA.maybeRestoreArchive uses the header of the archive file to create the
destination file for restore and if that target file already exists we throw an
exception and bail on startup. The external restore script can in theory modify
the destination filename but only to something which conforms to the defined
pattern, otherwise the files aren't picked up during replay. Because of this
constraint, the only thing the restore script can really do is modify the part
of the filename that maps to the segment id. However, if it does do that, the
file will be skipped anyway as CLR.recover(File) creates its descriptor from
the (modified) filename, meaning that when it actually replays it, checksums
fail due to the mismatched descriptor id.
That said, it's pretty trivial to add a check for duplicate segments during
recovery, so if I've missed something let me know & I'll attach an updated
patch.
On the native archive, I'd rather we handle any general rework of the archival
process as a separate ticket if nobody objects.
> commitlog segments may not be archived after restart
> ----------------------------------------------------
>
> Key: CASSANDRA-6904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6904
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Sam Tunnicliffe
> Fix For: 2.0.11, 2.1.1
>
> Attachments: 2.0-6904.txt, 2.1-6904.txt
>
>
> commitlog segments are archived when they are full, so the current active
> segment will not be archived on restart (and its contents will not be
> available for pitr).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
