CASSANDRA-21066 Full Repair for Tracked Keyspaces#4565
Closed
maedhroz wants to merge 1 commit intoapache:cep-45-mutation-trackingfrom
Closed
CASSANDRA-21066 Full Repair for Tracked Keyspaces#4565maedhroz wants to merge 1 commit intoapache:cep-45-mutation-trackingfrom
maedhroz wants to merge 1 commit intoapache:cep-45-mutation-trackingfrom
Conversation
9edc6c2 to
d74f11b
Compare
9ce9758 to
673e86f
Compare
maedhroz
commented
Jan 24, 2026
maedhroz
commented
Jan 25, 2026
f876476 to
7781a20
Compare
maedhroz
commented
Feb 1, 2026
maedhroz
commented
Feb 5, 2026
|
|
||
| import org.junit.Test; | ||
|
|
||
| public class TrackedNonZeroCopyRepairTransferTest extends TrackedRepairTransferTest |
Contributor
Author
There was a problem hiding this comment.
These tests, and their ZCS equivalents could probably just share a cluster and create a keysapce per test.
a5fe898 to
4492a7f
Compare
aratno
reviewed
Feb 7, 2026
src/java/org/apache/cassandra/replication/UnreconciledMutations.java
Outdated
Show resolved
Hide resolved
5cc0aa3 to
8d4ebae
Compare
Tracked keyspaces cannot accept new data without first registering it in the log. Any unreconciled data that isn't present in the log will break read monotonicity, since mutation tracking uses a single data read and can only read reconcile mutation IDs that are present in the log. Full repair sync tasks also deliver data to replicas, and require integration with the log just like imports do. The general design of this integration is to give repair SyncTasks the same two-phase commit as import transfers, where we stream SSTables to a pending directory, then once sufficient streams complete successfully, we "activate" those streams and move them out of the pending directory and into the live set. patch by Caleb Rackliffe; reviewed by Abe Ratnofsky for CASSANDRA-21066 Co-authored-by: Caleb Rackliffe <calebrackliffe@gmail.com> Co-authored-by: Abe Ratnofsky <abe@aber.io>
8d4ebae to
74e6c91
Compare
Contributor
Author
|
Committed as d482690 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tracked keyspaces cannot accept new data without first registering it in
the log. Any unreconciled data that isn't present in the log will break
read monotonicity, since mutation tracking uses a single data read and
can only read reconcile mutation IDs that are present in the log. For
more information about how bulk transfers work on tracked keyspaces, see
TrackedImportTransfer.
Full repair sync tasks also deliver data to replicas, and require
integration with the log just like imports do. For more details on a
read anomaly that could happen without integration with the bulk
transfer machinery, see
TrackedKeyspaceRepairSupportTest#testFullRepairPartiallyCompleteAnomaly.
The general design of this integration is to give repair SyncTasks the
same two-phase commit as import transfers, where we stream SSTables to a
pending/ directory, then once sufficient streams complete successfully,
we "activate" those streams and move them out of the pending directory
and into the live set.
The first step is to ensure that each SyncTask is aligned to a single
Mutation Tracking shard, by splitting SyncTasks along the shard
boundaries. Each SyncTask will then stream data within a single shard,
and permit us to assign a single transfer ID to each SyncTask.
Each participant in a repair may receive different SyncTasks (or none at
all, if they're already in-sync). This means that ActivationRequest must be flexible
enough to support transfers with multiple plan IDs or none at all.