You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by Apache Wiki <wi...@apache.org> on 2011/09/06 01:05:12 UTC

[Cassandra Wiki] Update of "Operations" by vijay2win

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 vijay2win:
http://wiki.apache.org/cassandra/Operations?action=diff&rev1=95&rev2=96

  
  The status of move and balancing operations can be monitored using `nodetool` with the `netstat` argument.  (Cassandra 0.6.* and lower use the `streams` argument).
  
+ === Replacing a Dead Node (with same token): ===
+ 
+ Since Cassandra 1.0 we can replace an existing node with a new node using the property "cassandra.replace_token=<Token>", This property can be set using -D option while starting cassandra demon process.
+ 
+ (Note:This property will be taken into effect only when the node doesn't have any data in it, You might want to empty the data dir if you want to force the node replace.)
+ 
+ You must use this property when replacing a dead node (If tried to replace an existing live node, the bootstrapping node will throw a Exception).
+ The token used via this property must be part of the ring and the node have died due to various reasons.
+ 
+ Once this Property is enabled the node starts in a hibernate state, during which all the other nodes will see this node to be down. The new node will now start to bootstrap the data from the rest of the nodes in the cluster (Main difference between normal bootstrapping of a new node is that this new node will not accept any writes during this phase). Once the bootstrapping is complete the node will be marked "UP", we rely on the hinted handoff's for making this node consistent (Since we don't accept writes since the start of the bootstrap).
+ 
+ Note: We Strongly suggest to repair the node once the bootstrap is completed, because Hinted handoff is a "best effort and not a guarantee".
+ 
  == Consistency ==
  Cassandra allows clients to specify the desired consistency level on reads and writes.  (See [[API]].)  If R + W > N, where R, W, and N are respectively the read replica count, the write replica count, and the replication factor, all client reads will see the most recent write.  Otherwise, readers '''may''' see older versions, for periods of typically a few ms; this is called "eventual consistency."  See http://www.allthingsdistributed.com/2008/12/eventually_consistent.html and http://queue.acm.org/detail.cfm?id=1466448 for more.
  
@@ -225, +238 @@

  NOTE: Starting with version 0.7, json2sstable and sstable2json must be run in such a way that the schema can be loaded from system tables.  This means that cassandra.yaml must be found in the classpath and refer to valid storage directories.
  
  == Monitoring ==
- Running `nodetool cfstats` can provide an overview of each Column Family, and important metrics to graph your cluster. Cassandra also exposes internal metrics as JMX data. This is a common standard in the JVM world; OpenNMS, Nagios, and Munin at least offer some level of JMX support. For a non-stupid JMX plugin for Munin check out https://github.com/tcurdt/jmx2munin 
+ Running `nodetool cfstats` can provide an overview of each Column Family, and important metrics to graph your cluster. Cassandra also exposes internal metrics as JMX data. This is a common standard in the JVM world; OpenNMS, Nagios, and Munin at least offer some level of JMX support. For a non-stupid JMX plugin for Munin check out https://github.com/tcurdt/jmx2munin
- The specifics of the JMX Interface are documented at JmxInterface. 
+ The specifics of the JMX Interface are documented at JmxInterface.
  
  Some folks prefer having to deal with non-jmx clients, there is a JMX-to-REST bridge available at http://code.google.com/p/polarrose-jmx-rest-bridge/ Bridging to SNMP is a bit more work but can be done with https://github.com/tcurdt/jmx2snmp