Francisco Guerrero created CASSANDRA-21626:
----------------------------------------------
Summary: CEP-45: Migration repair streams can write live SSTables
into pending/<planId>/ and lose them silently on restart
Key: CASSANDRA-21626
URL: https://issues.apache.org/jira/browse/CASSANDRA-21626
Project: Apache Cassandra
Issue Type: Bug
Components: Legacy/Streaming and Messaging
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero
During a mutation-tracking migration, some token ranges have already completed
migration while others are still pending.
{{KeyspaceMigrationInfo.shouldUseTrackedTransfers()}} is the single source of
truth for which path a given set of ranges should use, and
{{CassandraStreamReceiver.useTrackedTransferPath()}} wraps it correctly for the
registration decision made in {{finished()}} (whether to hand received SSTables
to {{MutationTrackingService.received()}} for coordinated activation, or add
them directly via {{cfs.addSSTables()}}).
However, we are not always using
{{KeyspaceMigrationInfo.shouldUseTrackedTransfers()}} to determine the
streaming write path on disk for the SSTable.
Today, all streams for a keyspace that is migrating, get routed to the
{{pending/<planId>/}} directory, even though {{finished()}} already correctly
classified the stream as untracked, and it never registered a
{{PendingLocalTransfer}} for it.
Now, the issue is that the SSTable lands on the {{pending/<planId>}} directory
without a durable pending-transfer record. The data is visible immediately
after repair, so repair reports success and the migration appears complete.
However, on node restart the pending directory recovery logic will discard the
orphaned (untracked) pending directory, and the data silently disappears with
no indication of what caused the data loss.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
