Author: jbellis
Date: Tue May 25 01:17:27 2010
New Revision: 947889

URL: http://svn.apache.org/viewvc?rev=947889&view=rev
Log:
document DatacenterShardStrategy.  patch by jbellis

Modified:
    cassandra/trunk/NEWS.txt
    cassandra/trunk/conf/cassandra.yaml
    cassandra/trunk/interface/cassandra.thrift

Modified: cassandra/trunk/NEWS.txt
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/NEWS.txt?rev=947889&r1=947888&r2=947889&view=diff
==============================================================================
--- cassandra/trunk/NEWS.txt (original)
+++ cassandra/trunk/NEWS.txt Tue May 25 01:17:27 2010
@@ -10,6 +10,9 @@ Features
     - A new ByteOrderedPartitioner supports bytes keys with arbitrary content,
       and orders keys by their byte value. 
     - Truncate thrift method allows clearing an entire ColumnFamily at once
+    - DatacenterShardStrategy is ready for use, enabling 
+      ConsitencyLevel.DCQUORUM and DCQUORUMSYNC.  See comments in
+      `cassandra.yaml.`
 
 Configuraton
 ------------

Modified: cassandra/trunk/conf/cassandra.yaml
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/conf/cassandra.yaml?rev=947889&r1=947888&r2=947889&view=diff
==============================================================================
--- cassandra/trunk/conf/cassandra.yaml (original)
+++ cassandra/trunk/conf/cassandra.yaml Tue May 25 01:17:27 2010
@@ -132,10 +132,24 @@ endpoint_snitch: org.apache.cassandra.lo
 # - replica_placement_strategy: the class that determines how replicas
 #   are distributed among nodes.  Must implement IReplicaPlacementStrategy.
 #   Out of the box, Cassandra provides 
-#   org.apache.cassandra.locator.RackUnawareStrategy and
-#   org.apache.cassandra.locator.RackAwareStrategy.  RackAwareStrategy
-#   place one replica in each of two datacenter, and other replicas in
-#   different racks in one.
+#     * org.apache.cassandra.locator.RackUnawareStrategy 
+#     * org.apache.cassandra.locator.RackAwareStrategy
+#     * org.apache.cassandra.locator.DatacenterShardStrategy
+#
+#   RackUnawareStrategy is the simplest; it simply places the first
+#   replica at the node whose token is closest to the key (as determined
+#   by the Partitioner), and additional replicas on subsequent nodes
+#   along the ring in increasing Token order.
+# 
+#   RackAwareStrategy is special cased for replication_factor of 3.  It
+#   places one replica in each of two datacenters, and the third on a
+#   different rack in in the first.
+#
+#   DatacenterShardStrategy is a generalization of RackAwareStrategy.
+#   For each datacenter, you can specify (in `datacenter.properties`)
+#   how many replicas you want on a per-keyspace basis.  Replicas are
+#   placed on different racks within each DC, if possible.
+# 
 # - replication_factor: Number of replicas of each row
 # - column_families: column families associated with this keyspace
 #

Modified: cassandra/trunk/interface/cassandra.thrift
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/interface/cassandra.thrift?rev=947889&r1=947888&r2=947889&view=diff
==============================================================================
--- cassandra/trunk/interface/cassandra.thrift (original)
+++ cassandra/trunk/interface/cassandra.thrift Tue May 25 01:17:27 2010
@@ -137,22 +137,23 @@ exception AuthorizationException {
  * allowing availability in the face of node failures up to half of 
<ReplicationFactor>. Of course if latency is more
  * important than consistency then you can use lower values for either or both.
  *
- * Write:
- *      ZERO    Ensure nothing. A write happens asynchronously in background
- *      ANY     Ensure that the write has been written once somewhere, 
including possibly being hinted in a non-target node.
- *      ONE     Ensure that the write has been written to at least 1 node's 
commit log and memory table before responding to the client.
- *      QUORUM  Ensure that the write has been written to <ReplicationFactor> 
/ 2 + 1 nodes before responding to the client.
- *      ALL     Ensure that the write is written to 
<code>&lt;ReplicationFactor&gt;</code> nodes before responding to the client.
+ * Write consistency levels make the following guarantees before reporting 
success to the client:
+ *   ZERO         Ensure nothing. A write happens asynchronously in background
+ *   ANY          Ensure that the write has been written once somewhere, 
including possibly being hinted in a non-target node.
+ *   ONE          Ensure that the write has been written to at least 1 node's 
commit log and memory table
+ *   QUORUM       Ensure that the write has been written to 
<ReplicationFactor> / 2 + 1 nodes
+ *   DCQUORUM     Ensure that the write has been written to 
<ReplicationFactor> / 2 + 1 nodes, within the local datacenter (requires 
DatacenterShardStrategy)
+ *   DCQUORUMSYNC Ensure that the write has been written to 
<ReplicationFactor> / 2 + 1 nodes in each datacenter (requires 
DatacenterShardStrategy)
+ *   ALL          Ensure that the write is written to 
<code>&lt;ReplicationFactor&gt;</code> nodes before responding to the client.
  *
  * Read:
- *      ZERO    Not supported, because it doesn't make sense.
- *      ANY     Not supported. You probably want ONE instead.
- *      ONE     Will return the record returned by the first node to respond. 
A consistency check is always done in a
- *              background thread to fix any consistency issues when 
ConsistencyLevel.ONE is used. This means subsequent
- *              calls will have correct data even if the initial read gets an 
older value. (This is called 'read repair'.)
- *      QUORUM  Will query all storage nodes and return the record with the 
most recent timestamp once it has at least a
- *              majority of replicas reported. Again, the remaining replicas 
will be checked in the background.
- *      ALL     Queries all storage nodes and returns the record with the most 
recent timestamp.
+ *   ZERO         Not supported, because it doesn't make sense.
+ *   ANY          Not supported. You probably want ONE instead.
+ *   ONE          Will return the record returned by the first node to 
respond. A consistency check is always done in a background thread to fix any 
consistency issues when ConsistencyLevel.ONE is used. This means subsequent 
calls will have correct data even if the initial read gets an older value. 
(This is called 'read repair'.)
+ *   QUORUM       Will query all storage nodes and return the record with the 
most recent timestamp once it has at least a majority of replicas reported. 
Again, the remaining replicas will be checked in the background.
+ *   DCQUORUM     Returns the record with the most recent timestamp once a 
majority of replicas within the local datacenter have replied.
+ *   DCQUORUMSYNC Returns the record with the most recent timestamp once a 
majority of replicas within each datacenter have replied.
+ *   ALL          Queries all storage nodes and returns the record with the 
most recent timestamp.
 */
 enum ConsistencyLevel {
     ZERO = 0,


Reply via email to