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

Stefan Miklosovic commented on CASSANDRA-19448:
-----------------------------------------------

[CASSANDRA-19448-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19448-trunk]
{noformat}
java17_pre-commit_tests                         
  ✓ j17_build                                         5m 8s
  ✓ j17_cqlsh_dtests_py311                           7m 22s
  ✓ j17_cqlsh_dtests_py311_vnode                     7m 39s
  ✓ j17_cqlsh_dtests_py38                             7m 1s
  ✓ j17_cqlsh_dtests_py38_vnode                       7m 2s
  ✓ j17_cqlshlib_cython_tests                       10m 46s
  ✓ j17_cqlshlib_tests                               9m 39s
  ✓ j17_dtests                                      35m 19s
  ✓ j17_dtests_vnode                                36m 24s
  ✓ j17_unit_tests                                  15m 58s
  ✓ j17_unit_tests_repeat                            9m 17s
  ✓ j17_utests_latest                               14m 40s
  ✓ j17_utests_latest_repeat                         9m 36s
  ✓ j17_utests_oa_repeat                             9m 23s
  ✕ j17_dtests_latest                               35m 24s
      replica_side_filtering_test.TestSecondaryIndexes 
test_complementary_deletion_with_limit_on_clustering_key_column
      replica_side_filtering_test.TestSecondaryIndexes 
test_complementary_deletion_with_limit_on_partition_key_column_with_not_empty_partitions
  ✕ j17_jvm_dtests                                  23m 18s
      org.apache.cassandra.fuzz.ring.ConsistentBootstrapTest 
coordinatorIsBehindTest
      
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest 
testEndpointVerificationEnabledIpNotInSAN TIMEOUTED
      
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
 testConcurrentReadWriteWorkload
      org.apache.cassandra.distributed.test.tcm.SplitBrainTest 
testSplitBrainStartup
  ✕ j17_jvm_dtests_latest_vnode                     25m 46s
      org.apache.cassandra.distributed.test.tcm.CMSPlacementAfterMoveTest 
testMoveToCMS
  ✕ j17_utests_oa                                    15m 3s
      org.apache.cassandra.tcm.DiscoverySimulationTest discoveryTest
{noformat}

[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4723/workflows/4726de2e-5f9f-4b4c-a292-15ff94e5c488]


> 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: 3h
>  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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to