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