You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Maxwell Guo (Jira)" <ji...@apache.org> on 2024/04/01 13:46:00 UTC

[jira] [Comment Edited] (CASSANDRA-19448) CommitlogArchiver only has granularity to seconds for restore_point_in_time

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

Maxwell Guo edited comment on CASSANDRA-19448 at 4/1/24 1:45 PM:
-----------------------------------------------------------------

Hi Sorry for the late reply. I was in a hurry recently so I was away for a while. [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. 
I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. 
Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x.


||Heading 1||Heading 2||
|PR for trunk |[pr|https://github.com/apache/cassandra/pull/3215/]|

And the ci are running ,will check if the they finished.

||Heading 1||Heading 2||
|java11|[java11|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/549/workflows/f1110dc1-b08e-4db5-97bf-e945658dc28b]|
|java17|[java17|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/549/workflows/e9cf230a-9b78-4568-9ae4-14c0e68510a4]|


Update:
fix build error for unused imports 



was (Author: maxwellguo):
Hi Sorry for the late reply. I was in a hurry recently so I was away for a while. [~brandon.williams][~tiagomlalves] [~jeromatron], I have also made a PR for this ,And I might want a more general solution to this problem, whether rip is seconds, milliseconds, or microseconds. 
I have just prepare the pr but have not been tested very complete, here is the pr , and I will update the CI after they finished. 
Besides, I used to pay more attention to whether this category is a bug or an improvement, because it is related to whether to prepare a copy for 4.x.


||Heading 1||Heading 2||
|PR for trunk |[pr|https://github.com/apache/cassandra/pull/3215/]|

And the ci are running ,will check if the they finished.

||Heading 1||Heading 2||
|java11|[java11|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/8102b770-a623-4417-a5ea-5c602b7e6949]|
|java17|[java17|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/547/workflows/82eb1c09-ca27-46b0-996c-7d841e062423]|



> 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