Database Reference
In-Depth Information
method from the abstract parent implementation. This strategy places replicas in a single data
center, in a manner that is not aware of their placement on a data center rack. This means that
the implementation is theoretically fast, but not if the next node that has the given key is in a
different rack than others. This is shown in
Figure 6-1
.
Figure6-1.The Simple Strategy places replicas in a single data center, without respect to topology
What's happening here is that the next N nodes on the ring are chosen to hold replicas, and the
strategy has no notion of data centers. A second data center is shown in the diagram to highlight
the fact that the strategy is unaware of it.
Old Network Topology Strategy
The second strategy for replica placement that Cassandra provides out of the box is
org.apache.cassandra.locator.RackAwareStrategy
, now called Old Network Topology
Strategy. It's mainly used to distribute data across different racks in the same data center. Like
RackUnawareStrategy
, this strategy only overrides the
calculateNaturalEndpoints
meth-
od from the abstract parent implementation. This class, as the original name suggests, is indeed
aware of the placement in data center racks.
Say you have two data centers, DC1 and DC2, and a set of Cassandra servers. This strategy will
place some replicas in DC1, putting each in a different available rack. It will also ensure that an-
other replica is placed in DC2. The Rack-Aware Strategy is specifically for when you have nodes
in the same Cassandra cluster spread over two data centers and you are using a replication factor
of 3. This strategy is depicted in
Figure 6-2
.
Use this strategy when you want to ensure higher availability at the potential cost of some addi-
tional latency while the third node in the alternate data center is contacted. There is no point in
using Rack-Aware Strategy if you are only running Cassandra in a single data center. Cassandra
