[
https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450469#comment-17450469
]
Stefan Miklosovic commented on CASSANDRA-16619:
-----------------------------------------------
Maybe my wording was not precise enough so let me fix and reiterate on that.
As you said, when it detects that the commit log was not created on the node we
try to replay it on, it will effectively replay all mutations. I have a unit
test for this and I noticed that when I created 6 mutations and I took a
snapshot of that and I created two more mutations but I have not made a
snapshot of that but I backed up a commit log, when I replayed commit logs in
such a way that I was expecting 7 mutations to be present (6 from sstables + 1
from logs), I was still getting 8 mutations and after looking into the logs I
discovered that message which lead me to this ticket.
So in that sense - "restore_point_in_time" is effectively ignored in cases when
I want to restore to a completely new node because its host id will be
generated in such a way that it will not match the host id of the commit log I
want to replay - so it will replay all mutations - but I do not want that.
> Loss of commit log data possible after sstable ingest
> -----------------------------------------------------
>
> Key: CASSANDRA-16619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16619
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> SSTable metadata contains commit log positions of the sstable. These
> positions are used to filter out mutations from the commit log on restart and
> only make sense for the node on which the data was flushed.
> If an SSTable is moved between nodes they may cover regions that the
> receiving node has not yet flushed, and result in valid data being lost
> should these sections of the commit log need to be replayed.
> Solution:
> The chosen solution introduces a new sstable metadata (StatsMetadata) -
> originatingHostId (UUID), which is the local host id of the node on which the
> sstable was created, or null if not known. Commit log intervals from an
> sstable are taken into account during Commit Log replay only when the
> originatingHostId of the sstable matches the local node's hostId.
> For new sstables the originatingHostId is set according to StorageService's
> local hostId.
> For compacted sstables the originatingHostId set according to
> StorageService's local hostId, and only commit log intervals from local
> sstables is preserved in the resulting sstable.
> discovered by [~jakubzytka]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
