[ https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833365#comment-17833365 ]
Maxwell Guo commented on CASSANDRA-19448: ----------------------------------------- [~tiagomlalves]Thanks for you reply : bq. What I miss is the practical knowledge on how a customer can determine at microsecond level precision if something is being inserted in a cluster. In my mind, as for this , seconds and millseconds may meet the same question , and microseconds can more accurately express whether data is needed . 1、RIP is an abbreviation for error, and I have fixed it, thanks for reminding; 2、As for RIPLEVEL enum class, I classified it intentionally. If you think this code is redundant, I can change it. bq. I would be willing to to pick up where you left in https://github.com/apache/cassandra/pull/3215 and try out that simplification if you agree. of course you can , but before that you can see my my latest update. https://github.com/apache/cassandra/pull/3215/ > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org