cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "Operations" by JonathanEllis
Date Mon, 25 Jan 2010 16:15:26 GMT
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.
The comment on this change is: add GCGraceSeconds  explanation.
http://wiki.apache.org/cassandra/Operations?action=diff&rev1=26&rev2=27

--------------------------------------------------

   1. Anti-Entropy: when `nodetool repair` is run, Cassandra performs a major compaction,
computes a Merkle Tree of the data on that node, and compares it with the versions on other
replicas, to catch any out of sync data that hasn't been read recently.  This is intended
to be run infrequently (e.g., weekly) since major compaction is relatively expensive.
  
  === Handling failure ===
- If a node goes down and comes back up, the ordinary repair mechanisms will be adequate to
deal with any inconsistent data.  If a node goes down entirely, then you have two options:
+ If a node goes down and comes back up, the ordinary repair mechanisms will be adequate to
deal with any inconsistent data.  Remember though that if a node is down longer than your
configured !GCGraceSeconds (default: 10 days), it could have missed remove operations permanently.
 Unless your application performs no removes, you should wipe its data directory, re-bootstrap
it, and removetoken its old entry in ghe ring (see below).
+ 
+ If a node goes down entirely, then you have two options:
  
   1. (Recommended approach) Bring up the replacement node with a new IP address, and !AutoBootstrap
set to true in storage-conf.xml. This will place the replacement node in the cluster and find
the appropriate position automatically. Then the bootstrap process begins. While this process
runs, the node will not receive reads until finished. Once this process is finished on the
replacement node, run `nodetool removetoken` once, suppling the token of the dead node, and
`nodetool cleanup` on each node.
   * You can obtain the dead node's token by running `nodetool ring` on any live node, unless
there was some kind of outage, and the others came up but not the down one -- in that case,
you can retrieve the token from the live nodes' system tables.

Mime
View raw message