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
  

Reply via email to