[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-commits
Subject:    [jira] [Commented] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_p
From:       "Maxwell Guo (Jira)" <jira () apache ! org>
Date:       2024-03-30 7:23:00
Message-ID: JIRA.13570184.1709136027000.100044.1711783380042 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.pl \
ugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832409#comment-17832409 \
] 

Maxwell Guo commented on CASSANDRA-19448:
-----------------------------------------

The reason why I fixed it like this is because I want to make the rip time \
configurable in seconds, milliseconds, and microseconds level . I think microseconds \
is the upper limit because the upper limit of c* timestamp is this; Then the original \
method converts the timestamp to milliseconds by default see \
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2761] \
and [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L498]. \
I feel that the timestamp granularity should be aligned with the timestamp of c*, and \
then the user granularity configuration can be selected for the rip time.

[~brandon.williams][~tiagomlalves] WDYT ?  

> CommitlogArchiver only has granularity to seconds for restore_point_in_time
> ---------------------------------------------------------------------------
> 
> Key: CASSANDRA-19448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19448
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
> Reporter: Jeremy Hanna
> Assignee: Maxwell Guo
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
> 
> Time Spent: 10m
> Remaining Estimate: 0h
> 
> Commitlog archiver allows users to backup commitlog files for the purpose of doing \
> point in time restores.   The [configuration \
> file|https://github.com/apache/cassandra/blob/trunk/conf/commitlog_archiving.properties] \
> gives an example of down to the seconds granularity but then asks what whether the \
> timestamps are microseconds or milliseconds - defaulting to microseconds.   Because \
> the [CommitLogArchiver uses a second based date \
> format|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java#L52], \
> if a user specifies to restore at something at a lower granularity like \
> milliseconds or microseconds, that means that the it will truncate everything after \
> the second and restore to that second.  So say you specify a restore_point_in_time \
> like this: restore_point_in_time=2024:01:18 17:01:01.623392
> it will silently truncate everything after the 01 seconds.  So effectively to the \
> user, it is missing updates between 01 and 01.623392. This appears to be a bug in \
> the intent.  We should allow users to specify down to the millisecond or even \
> microsecond level. If we allow them to specify down to microseconds for the restore \
> point in time, then it may internally need to change from a long.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]