Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "Operations" page has been changed by JonathanEllis. http://wiki.apache.org/cassandra/Operations?action=diff&rev1=1&rev2=2 -------------------------------------------------- + The following applies to Cassandra 0.5, which is currently in '''beta'''. + = Ring management = Each Cassandra server [node] is assigned a unique Token that determines what keys it is the primary replica for. If you sort all nodes' Tokens, the Range of keys each is responsible for is (!PreviousToken, !MyToken], that is, from the previous token (exclusive) to the node's token (inclusive). The machine with the lowest Token gets both all keys less than that token, and all keys greater than the largest Token; this is called a "wrapping Range." @@ -8, +10 @@ When the !RandomPartitioner is used, Tokens are integers from 0 to 2**127. Keys are converted to this range by MD5 hashing for comparison with Tokens. (Thus, keys are always convertible to Tokens, but the reverse is not always true.) - == Multiple Datacenters == + == Token selection == + + Using a strong hash function means !RandomPartitioner keys will, on average, be evenly spread across the Token space, but you can still have imbalances if your Tokens do not divide up the range evenly, so you should specify InitialToken to your first nodes as `i * (2**127 / N)` for i = 1 .. N. + + With order preserving partioners, your key distribution will be application-dependent. You should still take your best guess at specifying initial tokens (guided by sampling actual data, if possible), but you will be more dependent on active load balancing (see below) and/or adding new nodes to hot spots. + + Once data is placed on the cluster, the partitioner may not be changed without wiping and starting over. + + == Replication == + + A Cassandra cluster always divides up the key space into ranges delimited by Tokens as described above, but additional replica placement is customizable via !IReplicaPlacementStrategy in the configuration file. The standard strategies are + * !RackUnawareStrategy: replicas are always placed on the next (in increasing Token order) N-1 nodes along the ring + * !RackAwareStrategy: replica 2 is is placed in the first node along the ring the belongs in '''another''' data center than the first; the remaining N-2 replicas, if any, are placed on the first nodes along the ring in the '''same''' rack as the first + + Note that with !RackAwareStrategy, succeeding nodes along the ring should alternate data centers to avoid hot spots. For instance, if you have nodes A, B, C, and D in increasing Token order, and instead of alternating you place A and B in DC1, and C and D in DC2, then nodes C and A will have disproportionately more data on them because they will be the replica destination for every Token range in the other data center. + + Replication strategy may not be changed without wiping your data and starting over. = Adding new nodes = @@ -18, +36 @@ If you explicitly specify an InitialToken in the configuration, the new node will bootstrap to that position on the ring. Otherwise, it will pick a Token that will give it half the keys from the node with the most disk space used, that does not already have another node boostrapping into its Range. + Important things to note: + 1. You should wait long enough for all the nodes in your cluster to become aware of the bootstrapping node via gossip before starting another bootstrap. For most clusters 30s will be plenty of time. + 1. Automatically picking a Token only allows doubling your cluster size at once; for more than that, let the first group finish before starting another. + 1. As a safety measure, Cassandra does not automatically remove data from nodes that "lose" part of their Token Range to a newly added node. Run "nodeprobe cleanup" on the source node(s) when you are satisfied the new node is up and working. If you do not do this the old data will still be counted against the load on that node and future bootstrap attempts at choosing a location will be thrown off. + + = Removing nodes entirely = + + You can take a node out of the cluster with `nodeprobe decommission.` The node must be live at decommission time (until CASSANDRA-564 is done). + + Again, no data is removed automatically, so if you want to put the node back into service and you don't need the data on it anymore, it should be removed manually. + = Moving nodes = + + Moving is essentially a convenience over decommission + bootstrap. = Load balancing = + Also essentially a convenience over decommission + bootstrap, only instead of telling the node where to move on the ring it will choose its location based on the same heuristic as Token selection on bootstrap. + + = Consistency = + + = Repairing missing or inconsistent data = +
