cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cassandra Wiki] Update of "Operations" by TedZ
Date Thu, 25 Feb 2010 15:37:57 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 TedZ.


  == 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
and for more.
+ See below about consistent backups.
  === Repairing missing or inconsistent data ===
  Cassandra repairs data in two ways:
@@ -108, +110 @@

  Currently, only flushed data is snapshotted (not data that only exists in the commitlog).
 Run `nodetool flush` first and wait for that to complete, to make sure you get '''all'''
data in the snapshot.
  To revert to a snapshot, shut down the node, clear out the old commitlog and sstables, and
move the sstables from the snapshot location to the live data directory.
+ === Consistent backups ===
+ You can get an eventually consistent backup by flushing all nodes and snapshotting; no individual
node's backup is guaranteed to be consistent but if you restore from that snapshot then clients
will get eventually consistent behavior as usual.
+ There is no such thing as a consistent view of the data in the strict sense, except in the
trivial case of writes with consistency level = ALL.
  === Import / export ===
  As an alternative to taking snapshots it's possible to export SSTables to JSON format using
the `bin/sstable2json` command:

View raw message