mirror of https://github.com/apache/cassandra
595b158958
During mutation tracking migration (tracked <-> untracked), the per-range migration state must be consulted for every routing decision. Before this change, all Paxos V1 and V2 paths used the static keyspace-level replicationType().isTracked() check, which does not reflect per-range migration state and produces incorrect routing decisions during migration. Coordinator-side routing: Replace all static isTracked() checks with MigrationRouter calls across StorageProxy (commitPaxos, sendCommit, isTrackedKeyspaceRequiringPaxosCommitForwarding, checkAndForwardCasIfNeeded, checkAndForwardConsensusReadIfNeeded), PaxosCommit (constructor, isTrackedKeyspaceRequiringForwarding), PaxosCommitAndPrepare, PaxosPrepare (start + isTracked field), PaxosPrepareRefresh, and PaxosState truncation acknowledgment. Handler-side validation: Add migration state validation to four Paxos replica handlers that receive messages carrying mutations or tracked reads: PaxosCommit.RequestHandler (direct V1/V2 commits), PaxosPrepare.RequestHandler (V2 prepare with tracked read), PaxosCommitAndPrepare.RequestHandler (combined commit+prepare), and PaxosPrepareRefresh.RequestHandler (refresh commits). Each uses the conditional-fetch pattern from AbstractMutationVerbHandler.checkReplicationMigration: compare the coordinator routing decision against the handler MigrationRouter result, fetch only on mismatch when the coordinator epoch is ahead (handler is behind and needs to catch up), throw CoordinatorBehindException when the coordinator epoch is behind. Coordinator-side commit retry: Add commit-level COORDINATOR_BEHIND retry in Paxos.cas() (V2) and commitPaxos() (V1). When replicas reject a commit due to migration state mismatch, ResponseVerbHandler.maybeFetchLogs() catches up the coordinator synchronously before delivering the failure. The retry re-creates the commit with fresh MigrationRouter routing. This retries only the commit phase, not the entire prepare+propose protocol. Stale mutation ID reconciliation: Commits saved in system.paxos may have a mutation ID from when the keyspace was tracked. When replayed after migration to untracked (via PaxosPrepareRefresh, PaxosCommitAndPrepare, sendCommit, or commitPaxos), the stale ID must be stripped to avoid Keyspace.apply() rejecting the mutation. Uses Commit.withMutationId() to reconcile in all four replay paths. Forward handlers: Forwarding is harmless -- the receiving replica re-executes the full CAS/read with its own fresh routing decisions, so no migration validation is needed at the forward boundary itself. Removed the "reject if keyspace not tracked" guards from CasForwardHandler and ConsensusReadForwardHandler (forwarding is now valid in either direction). Replaced unconditional fetchLogFromPeerOrCMS with the conditional-fetch pattern in Paxos2CommitForwardHandler, PaxosCommitForwardHandler, PrepareRefreshForwardHandler, and PaxosCommitAndPrepare.RequestHandler (unconditional fetch added unnecessary latency on the no-mismatch case). PaxosCommit failure tracking: Added super.onFailure() call to PaxosCommit.onFailure() so FailureRecordingCallback.failureResponses is populated, enabling failureReasonsAsMap() to return actual failure reasons. This was required for the V2 commit retry to detect COORDINATOR_BEHIND in MaybeFailure.failures. PaxosCommit hint suppression: Tracked mutations must not be written as hints because hint replay routes through Keyspace.applyInternalTracked() based on the mutation ID presence, which fails after migration to untracked. Guard submitHint with !isTracked() -- tracked mutations use MutationTrackingService for retries, not the hint system. MigrationRouter null safety: Replace getKeyspaceMetadata() (throws NoSuchElementException on missing keyspace) with maybeGetKeyspaceMetadata().orElse(null) at four call sites so the existing null guards actually protect against concurrent keyspace drops. |
||
|---|---|---|
| .build | ||
| .circleci | ||
| .github | ||
| .idea/codeStyles | ||
| .jenkins | ||
| bin | ||
| ci | ||
| conf | ||
| debian | ||
| doc | ||
| examples | ||
| ide | ||
| lib | ||
| modules | ||
| pylib | ||
| redhat | ||
| src | ||
| test | ||
| tools | ||
| .asf.yaml | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .gitmodules | ||
| .snyk | ||
| CASSANDRA-14092.txt | ||
| CHANGES.txt | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NEWS.txt | ||
| NOTICE.txt | ||
| README.asc | ||
| TESTING.md | ||
| build-shaded-dtest-jar.sh | ||
| build.properties.default | ||
| build.xml | ||
| relocate-dependencies.pom | ||
README.asc
image:https://img.shields.io/badge/License-Apache%202.0-blue.svg[License, link=https://github.com/apache/cassandra/blob/trunk/LICENSE.txt] image:https://ci-cassandra.apache.org/job/Cassandra-trunk/badge/icon[Build Status, link=https://ci-cassandra.apache.org/job/Cassandra-trunk/] image:https://img.shields.io/badge/Official-Downloads-brightgreen[Official Downloads, link=https://cassandra.apache.org/$$_$$/download.html] image:https://img.shields.io/docker/pulls/$$_$$/cassandra[Docker Pulls, link=https://hub.docker.com/r/$$_$$/cassandra] image:https://img.shields.io/badge/Slack-4A154B?style=flat&logo=slack&logoColor=white[Slack, link=https://infra.apache.org/slack.html] image:https://img.shields.io/badge/Bluesky-0285FF?logo=bluesky&logoColor=fff&color=0285FF[Bluesky, link=https://bsky.app/profile/cassandra.apache.org] image:https://img.shields.io/badge/-LinkedIn-blue?style=flat-square&logo=Linkedin&logoColor=white&link=https://www.linkedin.com/company/apache-cassandra/[LinkedIn, link=https://www.linkedin.com/company/apache-cassandra/] image:https://img.shields.io/badge/YouTube-FF0000?style=flat&logo=youtube&logoColor=white[Youtube, link=https://www.youtube.com/c/PlanetCassandra] Apache Cassandra ----------------- Apache Cassandra is a highly-scalable partitioned row store. Rows are organized into tables with a required primary key. https://cwiki.apache.org/confluence/display/CASSANDRA2/Partitioners[Partitioning] means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. https://cwiki.apache.org/confluence/display/CASSANDRA2/DataModel[Row store] means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL. For more information, see https://cassandra.apache.org/[the Apache Cassandra web site]. Issues should be reported on https://issues.apache.org/jira/projects/CASSANDRA/issues/[The Cassandra Jira]. Requirements ------------ - Java: see supported versions in build.xml (search for property "java.supported"). - Python: for `cqlsh`, see `bin/cqlsh` (search for function "is_supported_version"). Getting started --------------- This short guide will walk you through getting a basic one node cluster up and running, and demonstrate some simple reads and writes. For a more-complete guide, please see the Apache Cassandra website's https://cassandra.apache.org/doc/trunk/cassandra/getting-started/index.html[Getting Started Guide]. First, we'll unpack our archive: $ tar -zxvf apache-cassandra-$VERSION.tar.gz $ cd apache-cassandra-$VERSION After that we start the server. Running the startup script with the -f argument will cause Cassandra to remain in the foreground and log to standard out; it can be stopped with ctrl-C. $ bin/cassandra -f Now let's try to read and write some data using the Cassandra Query Language: $ bin/cqlsh The command line client is interactive so if everything worked you should be sitting in front of a prompt: ---- Connected to Test Cluster at localhost:9160. [cqlsh 6.3.0 | Cassandra 6.0-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] Use HELP for help. cqlsh> ---- As the banner says, you can use 'help;' or '?' to see what CQL has to offer, and 'quit;' or 'exit;' when you've had enough fun. But lets try something slightly more interesting: ---- cqlsh> CREATE KEYSPACE schema1 WITH replication = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 }; cqlsh> USE schema1; cqlsh:Schema1> CREATE TABLE users ( user_id varchar PRIMARY KEY, first varchar, last varchar, age int ); cqlsh:Schema1> INSERT INTO users (user_id, first, last, age) VALUES ('jsmith', 'John', 'Smith', 42); cqlsh:Schema1> SELECT * FROM users; user_id | age | first | last ---------+-----+-------+------- jsmith | 42 | john | smith cqlsh:Schema1> ---- If your session looks similar to what's above, congrats, your single node cluster is operational! For more on what commands are supported by CQL, see https://cassandra.apache.org/doc/trunk/cassandra/developing/cql/index.html[the CQL reference]. A reasonable way to think of it is as, "SQL minus joins and subqueries, plus collections." Wondering where to go from here? * Join us in #cassandra on the https://s.apache.org/slack-invite[ASF Slack] and ask questions. * Subscribe to the Users mailing list by sending a mail to user-subscribe@cassandra.apache.org. * Subscribe to the Developer mailing list by sending a mail to dev-subscribe@cassandra.apache.org. * Visit the https://cassandra.apache.org/community/[community section] of the Cassandra website for more information on getting involved. * Visit the https://cassandra.apache.org/doc/latest/development/index.html[development section] of the Cassandra website for more information on how to contribute.