[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834854#comment-17834854
]
Stefan Miklosovic edited comment on CASSANDRA-19130 at 4/8/24 9:53 AM:
-----------------------------------------------------------------------
few observations while I was working on the patch
1) there is this
https://github.com/instaclustr/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2756-L2762
With the proposed patch, when we "inject" timestamp into that method, if this
logic kicks in, then we would have different timestamp resolved from what we
provided, so timestamp might be "node-specific" again, depending on whether
there is some kind of a drift or not. I don't think this is desirable so I
would just get rid of that code completely, I am just not completely sure about
the consequences of doing so.
2) What happens with the truncation when there is a mixed cluster in place? Eg.
5.0 GA + 5.1. So, on 5.1, when I execute TRUNCATE, TCM will disperse this to
5.1 nodes only, how to ensure that this will work for 5.0 nodes too? Doesn't
there need to be some kind of a "bridge" to support this as well? Or do we say
that we can not truncate in a mixed-version cluster and we just reject this?
3) Related to 2), when TRUNCATE is executed on a 5.0 node in mixed-version
cluster with 5.1+ nodes, then we need to support this too. I think this is
actually easier, becase if StorageProxy.truncateBlocking() on 5.0 sends
TruncateRequest-s, it will be still treated by TruncateVerbHandler. We can
leave TruncateVerbHandler in 5.1 even this would be merged so we are covered in
this scenario. We would need to live with TruncateVerbHandler and
TruncateRequest as long as we support upgrades from non-transactional
truncation clusters to transactional-truncation ones.
4) When treating a TruncationRequest to 5.1 node from 5.0, in
TruncateVerbHandler, it is tempting to integrate this with TCM too, so we would
commit in doVerb method. Then the listener would be triggered and the
truncation would be executed. However, this is inherently asynchronous, so we
would commit truncation transformation, but we would return successful message
to the caller saying that truncation was done. But, it was not, _yet_. On the
other hand, I think we can consider it to be truncated and return immediately
because ... well ... it is meant to eventually executed ...
5) I also decided to not include vtables into beign transactionally truncated
because it doesnt make sense as described above.
6) what timestamp resolution we should use? We might go from millis to nanos,
basically. I based it all on millis for now.
was (Author: smiklosovic):
few observations while I was working on the patch
1) there is this
https://github.com/instaclustr/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2756-L2762
With the proposed patch, when we "inject" timestamp into that method, if this
logic kicks in, then we would have different timestamp resolved from what we
provided, so timestamp might be "node-specific" again, depending on whether
there is some kind of a drift or not. I don't think this is desirable so I
would just get rid of that code completely, I am just not completely sure about
the consequences of doing so.
2) What happens with the truncation when there is a mixed cluster in place? Eg.
5.0 GA + 5.1. So, on 5.1, when I execute TRUNCATE, TCM will disperse this to
5.1 nodes only, how to ensure that this will work for 5.0 nodes too? Doesn't
there need to be some kind of a "bridge" to support this as well? Or do we say
that we can not truncate in a mixed-version cluster and we just reject this?
3) Related to 2), when TRUNCATE is executed on a 5.0 node in mixed-version
cluster with 5.1+ nodes, then we need to support this too. I think this is
actually easier, becase if StorageProxy.truncateBlocking() on 5.0 sends
TruncateRequest-s, it will be still treated by TruncateVerbHandler. We can
leave TruncateVerbHandler in 5.1 even this would be merged so we are covered in
this scenario. We would need to live with TruncateVerbHandler and
TruncateRequest as long as we support upgrades from non-transactional
truncation clusters to transactional-truncation ones.
4) When treating a TruncationRequest to 5.1 node from 5.0, in
TruncateVerbHandler, it is tempting to integrate this with TCM too, so we would
commit in doVerb method. Then the listener would be triggered and the
truncation would be executed. However, this is inherently asynchronous, so we
would commit truncation transformation, but we would return successful message
to the caller saying that truncation was done. But, it was not, _yet_. On the
other hand, I think we can consider it to be truncated and return immediately
because ... well ... it is meant to eventually executed ...
5) I also decided to not include vtables into beign transactionally truncated
because it doesnt make sense as described above.
> Implement transactional table truncation
> ----------------------------------------
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
> Reporter: Marcus Eriksson
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
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
