I read some additional threads concerning outdated snapshots and deleted data so if the VM snapshot is older than gc_grace_seconds I suppose that data deleted meanwhile for which the tombstones have been removed would come back to life again if I just restore the VM from a snapshot being older than gc_grace_seconds. So after restoring the VM snapshot I should make sure Cassandra doesn’t start up automatically with the outdated snapshot data. Then I could
1)either startup the node with the replace_address option (do I still need to clear data directories first to avoid that deleted data comes back to life again?) 2) restore a Cassandra snapshot being not older than gc_grace_seconds by physically replacing SSTables in the data directory (did I get it right that the node must be up for running StorageService or sstableloader?) and run nodetool repair afterwards. Is this correct? tsi wrote > OK, now supposing Cassandra is run in a VM that crashes and I restore it > from a snapshot done some time ago. Data is stored redundantly > (replication factor 3) and I'm using consistency level QUORUM for reads > and writes. That means no data should be lost as the latest data will at > least be stored on another node. Now what do I have to do to sync the > "dead node" again after restoring the VM from the snapshot? Will a > nodetool repair command be sufficient? -- View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Replacing-a-dead-node-in-Cassandra-2-0-8-tp7596245p7596454.html Sent from the cassandra-u...@incubator.apache.org mailing list archive at Nabble.com.
