Database Reference
In-Depth Information
and gossip about changes to the schema. This is a one-time operation that stores the definition
in Cassandra's system keyspace, and you don't want to modify the YAML file after running this.
For any subsequent changes, you'll need to use the API or CLI. This operation will be deprec-
ated once the transition is complete.
Although it's simple enough for testing to just use the defaults, let's examine how to configure
the replica placement strategy, replication factor, and end point snitch. These settings are config-
urable within a keyspace, so that different keyspaces can have different settings for each.
Replicas
The replica placement strategy becomes more important the more nodes you add to your cluster.
In Cassandra, the term noderefers to the most general case; it means a server running the Cas-
sandra software, participating in a ring of one or more Cassandra servers.
Every Cassandra node is a replica for something. For a given key range, there may be some Cas-
sandra nodes that are not replicas for that range. If the replication factor is set to 1, writes are
written only to a single node. If that node goes down, the values stored on that node are not
accessible. If the replication factor is set to 2, two of the nodes in your cluster will get the value
written to them on every write, and they will be replicas for each other. So if your replication
factor is set to N, then each node will act as a replica for N ranges, even if N is set to
1
.
A Cassandra cluster, or collection of hosts, is typically referred to as a ring, for reasons we'll
see now. Each node in the ring is assigned a single, unique token. Each node claims ownership
of the range of values from its token to the token of the previous node. This is captured in the
org.apache.cassandra.dht.Range
class. Exactly how a token is represented is dependent on
the partitioner you're using. (For more information on partitioners, see
Partitioners
later in this
chapter.)
When creating a replica, the first replica is always placed in the node claiming the key range of
its token. All remaining replicas are distributed according to a configurable replication strategy,
which we'll look at now.
Replica Placement Strategies
In its simplest terms, to satisfy the replica placement strategy for the configuration file, you
just need to provide the name of a Java class that extends the
org.apache.cas-
sandra.locator.AbstractReplicationStrategy
class. The purpose of this setting is to
configure the way that the node picker works.
