[
https://issues.apache.org/jira/browse/CASSANDRA-15292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent White updated CASSANDRA-15292:
--------------------------------------
Description:
During point-in-time recovery
org.apache.cassandra.db.partitions.PartitionUpdate#maxTimestamp is checked to
see if any write timestamps in the update exceed the recovery point. If any of
the timestamps do exceed this point the the commit log replay is stopped.
Currently maxTimestamp only iterates over the regular rows in the update and
doesn't check for any included updates to static columns. If a ParitionUpdate
only contains updates to static columns then maxTimestamp will return
Long.MIN_VALUE and always be replayed.
This generally isn't much of an issue, except for non-dense compact storage
tables which are implemented in the 3.x storage engine in large part with
static columns. In this case the commit log will always continue applying
updates to them past the recovery point until it hits an update to a different
table with regular columns or reaches the end of the commit logs.
||Patch||
|[3.11|https://github.com/vincewhite/cassandra/commits/3_11_check_static_column_timestamps_commit_log_archive]|
|Trunk|
was:
During point-in-time recovery
org.apache.cassandra.db.partitions.PartitionUpdate#maxTimestamp is checked to
see if any write timestamps in the update exceed the recovery point. If any of
the timestamps do exceed this point the the commit log replay is stopped.
Currently maxTimestamp only iterates over the regular rows in the update and
doesn't check for any included updates to static columns. If a ParitionUpdate
only contains updates to static columns then maxTimestamp will return
Long.MIN_VALUE and always be replayed.
This generally isn't much of an issue, except for non-dense compact storage
tables which are implemented in the 3.x storage engine in large part with
static columns. In this case the commit log will always continue applying
updates to them past the recovery point until it hits an update to a different
table with regular columns or reaches the end of the commit logs.
||Patch||
|[3.11|http://example.com/]|
|Trunk|
> Point-in-time recovery ignoring timestamp of static column updates
> ------------------------------------------------------------------
>
> Key: CASSANDRA-15292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15292
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
> Reporter: Vincent White
> Priority: Normal
>
> During point-in-time recovery
> org.apache.cassandra.db.partitions.PartitionUpdate#maxTimestamp is checked to
> see if any write timestamps in the update exceed the recovery point. If any
> of the timestamps do exceed this point the the commit log replay is stopped.
> Currently maxTimestamp only iterates over the regular rows in the update and
> doesn't check for any included updates to static columns. If a ParitionUpdate
> only contains updates to static columns then maxTimestamp will return
> Long.MIN_VALUE and always be replayed.
> This generally isn't much of an issue, except for non-dense compact storage
> tables which are implemented in the 3.x storage engine in large part with
> static columns. In this case the commit log will always continue applying
> updates to them past the recovery point until it hits an update to a
> different table with regular columns or reaches the end of the commit logs.
>
> ||Patch||
> |[3.11|https://github.com/vincewhite/cassandra/commits/3_11_check_static_column_timestamps_commit_log_archive]|
> |Trunk|
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
