CASSANDRA-21674 CEP-46: update witness replication validation restrictions - #5155
Open
bdeggleston wants to merge 7 commits into
Open
CASSANDRA-21674 CEP-46: update witness replication validation restrictions#5155bdeggleston wants to merge 7 commits into
bdeggleston wants to merge 7 commits into
Conversation
Witness replicas require mutation tracking, and tracked reads never build a repairing ReadRepair, so the read_repair table option cannot affect a read that reaches a witness. CASSANDRA-20930 disabled this check in CreateTableStatement but left the AlterTableStatement and CopyTableStatement copies in place.
Reads for a range still pending migration take the untracked path, which refuses transient replicas, and those ranges rely on blocking read repair that a witness cannot serve. Two conditions are needed because AlterSchema starts the migration after the statement validates, so a statement that both enables tracking and adds witnesses cannot be seen in the migration state.
A promoted witness holds no data for the range it witnessed and quorum reads would count it, so promotion needs cassandra.allow_unsafe_witness_promotion, which is settable over JMX because QA performs it deliberately. The comparison is per datacenter, since NetworkTopologyStrategy sums its per-datacenter factors and aggregates hide a promotion offset by a reduction elsewhere. Dropping a witness stays legal: replica ordering removes it from the replica set rather than promoting it, and the remaining full replicas already hold the data.
Witnesses never serve data reads, since TrackedRead picks a full replica and summaries are built from the mutation tracking log, so an index on a witness is never consulted. The restriction was also asymmetric: CREATE INDEX on an existing witness keyspace was already accepted. Also drops a constant in CreateIndexStatement that was declared and referenced nowhere.
A counter leader resolves the increment against its local data, which a witness does not have for the range it witnesses, so it would write a value discarding every prior increment. findCounterLeaderReplica now considers only full replicas, and TrackedWriteRequest forwards rather than leading when the local replica is a witness.
A tracked prepare sends its data request to one participant and summary requests to the rest, so a witness votes without being asked for data it does not have. Extracts the selection into PaxosPrepare#selectDataNode so the test drives production code rather than a copy of it. No behaviour change.
The list of unsupported features was inherited from 4.0 and most of it no longer holds: lightweight transactions, secondary indexes and counters all work. Records what is actually enforced, why materialized views remain rejected, and the sequences for adopting and removing witnesses.
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
1 participant
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.
Thanks for sending a pull request! Here are some tips if you're new here:
Commit messages should follow the following format:
The Cassandra Jira