[
https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450494#comment-17450494
]
Branimir Lambov edited comment on CASSANDRA-16619 at 11/29/21, 2:36 PM:
------------------------------------------------------------------------
Rechecking the code, the point in time in restores is applied in
{{MutationInitiator.initiateMutation}}
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L247].
What this patch may change is the filtering by commit log position done [later
in the same
method|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L265].
I still do not see any evidence that this patch is affecting PIT restore in any
way, other than making replay slower because it could be needlessly replaying
mutations that are already present in sstables. Granted, the latter is an issue
and may warrant risking correctness by flagging this out, but reusing the same
ID through porting CASSANDRA-14582 to earlier versions is most probably a
better solution.
was (Author: blambov):
Rechecking the code, the point in time in restores is applied in
{{MutationInitiator.initiateMutation}}
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L247].
What this patch may change is the filtering by commit log position done [later
in the same
method|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L265].
I still do not see any evidence that this patch is affecting PIT restore in any
way, other than making replay slower because it could be needlessly replaying
mutations that are already present in sstables. Granted, the latter is an issue
and may warrant risking correctness by flagging this out, but reusing the same
ID as in CASSANDRA-14582 is most probably a better solution.
> 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
