[
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]