[
https://issues.apache.org/jira/browse/CASSANDRA-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881076#comment-17881076
]
Stefan Miklosovic commented on CASSANDRA-19448:
-----------------------------------------------
These 7h for cqlshlib is a bug on Circle side. There were some outages today
and it just messed stuff up when it comes to run times. These jobs just passed
fine, they are still marked as not finished.
[CASSANDRA-19448-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19448-4.1]
{noformat}
java11_pre-commit_tests
✓ j11_build 1m 45s
✓ j11_cqlsh_dtests_py3 6m 36s
✓ j11_cqlsh_dtests_py311 5m 40s
✓ j11_cqlsh_dtests_py311_vnode 6m 42s
✓ j11_cqlsh_dtests_py38 5m 39s
✓ j11_cqlsh_dtests_py38_vnode 5m 56s
✓ j11_cqlsh_dtests_py3_vnode 6m 5s
✓ j11_jvm_dtests_vnode 12m 11s
✓ j11_unit_tests 10m 28s
✓ j11_unit_tests_repeat 11m 39s
j11_cqlshlib_cython_tests 7h 15m 31s
j11_cqlshlib_tests 7h 15m 31s
✕ j11_dtests 40m 7s
largecolumn_test.TestLargeColumn test_cleanup
✕ j11_dtests_vnode 37m 56s
largecolumn_test.TestLargeColumn test_cleanup
✕ j11_jvm_dtests 18m 20s
org.apache.cassandra.distributed.test.RepairTest
testForcedNormalRepairWithOneNodeDown
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4709/workflows/6a2bb4a3-6378-44ab-a725-a2f10ad629e5]
> 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]
