[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837854#comment-17837854
]
Abe Ratnofsky commented on CASSANDRA-19130:
-------------------------------------------
> What happens with the truncation when there is a mixed cluster in place?
I would think that we should continue handle TruncateStatement in the pre-TCM
way, even when coordinated by an instance running with TCM, until the entire
cluster is known to be on TCM. Specifically, that would mean checking that all
instances are available, sending TRUNCATE_REQ to all peers and waiting for
responses, etc. Once the entire cluster is on TCM, we stop sending TRUNCATE_REQ
and ignore received TRUNCATE_REQ[1], and from then onwards all execution of
truncate happens via the TCM log listener.
[1]: We should warn if we receive a TRUNCATE_REQ after the entire cluster is on
TCM, since it should only be possible to receive one if a strange message
delivery happens from a pre-upgraded instance
> 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
