Cassandra alpha2 allocates tokens without an existing keyspace
Cassandra 4.0-alpha2 lets token allocation use an explicit local replication factor. The preview also replaces snapshot dependencies and corrects repair messaging.
Choosing tokens for a new Cassandra node involves assumptions about replication. An allocator trying to balance replicated load needs to know how many replicas the topology will place in a datacenter. Taking that information from an existing keyspace is convenient once the keyspace exists. It is less convenient when provisioning the cluster that will eventually hold it.
Cassandra 4.0-alpha2 adds a configuration option for supplying that local replication factor directly. The release metadata dates the preview to 29 October 2019. Its tagged changelog identifies the allocation change as CASSANDRA-15260. This is a concrete improvement to cluster initialization within an alpha release that also corrects dependencies and repair internals.
I am interested in Cassandra when active-active operation justifies its operational demands. A provisioning option like this matters because topology choices begin before applications create their tables. Configuration that can express the intended replication directly makes that initialization dependency easier to understand.
The allocator needs a replication assumption
The configuration shipped with alpha2 describes automatic allocation of num_tokens tokens. The algorithm attempts to choose tokens that optimize replicated load across nodes in a datacenter. According to those comments, load should be close to proportional to the number of virtual nodes assigned to each node.
The existing allocate_tokens_for_keyspace setting derives the replication factor from the named keyspace's strategy. The new setting expresses it without that lookup. Its documented example uses a local factor of three:
allocate_tokens_for_local_replication_factor: 3
The value is the replication factor within the datacenter, in the sense used by NetworkTopologyStrategy. It is not a request to create a keyspace, and it does not set the replication policy of a table's keyspace. It supplies an assumption to token allocation. Keeping those actions distinct prevents a plausible configuration misunderstanding.
For example, declaring a local factor for the allocator does not establish that a subsequently created keyspace uses the same factor. The administrator still chooses that keyspace's replication options. The allocation assumption and the later schema decision can agree, but one does not automatically enforce the other.
The comments also constrain the feature to Murmur3Partitioner. That requirement belongs to the allocator, so the configuration should not be treated as a partitioner-independent balancing switch. The feature operates inside the token model already described by the surrounding settings.
Removing a dependency during initialization
The practical benefit is avoiding the need for a suitable keyspace merely to describe the replication factor used by allocation. This allows provisioning configuration to carry the intended local value before application schema exists. It removes a dependency between infrastructure initialization and a named schema object.
That is useful even when both steps are automated. An automation system otherwise needs a keyspace to exist early enough for allocation to inspect it. Supplying the number directly makes that requirement explicit in the node configuration. The cost is that the number must remain consistent with the intended deployment design.
I prefer the explicit setting when assessing what a provisioning definition actually means. A keyspace name can conceal the replication assumption behind another lookup. The numeric option states the input to allocation in the same place as the token settings, while leaving keyspace replication as a separate decision.
The alpha2 configuration retains initial_token for explicit token assignment and describes its use with virtual nodes and legacy arrangements. Automatic allocation therefore remains one supported way to select tokens. Adding the local-factor input does not imply that every installation should discard an existing token assignment scheme.
A preview also has to be reproducible
The changelog records replacement of snapshot dependencies in the alpha. Chronicle Core moves to a stable version, and the Java driver moves from a snapshot dependency to 3.6.0. Guava also moves to version 27. These changes concern the composition of the release artifact, separately from token allocation behavior.
A snapshot dependency makes a release harder to reason about because its name denotes development material. Replacing that dependency with a stable version gives evaluators a more specific component to identify. The important point here is the release's declared dependency change, not an unsupported claim that dependency stabilization proves the database correct.
Repair work continues too. CASSANDRA-15163 restructures the RepairMessage hierarchy and corrects its use of the newer messaging implementation. The release also includes a compressed-writer resource-leak correction and startup gossip changes inherited from older release lines. Those entries show why alpha2 should be assessed as a distinct artifact, even when the major-version feature list looks familiar.
The Apache distribution archive supplies separately named binary and source distributions with signature and checksum files. This gives the preview a concrete published identity. For this release, the new token-allocation input is part of that identity, along with the dependency and messaging corrections recorded in its own changelog.