Restoring cassandra from snapshot -


so did of test run/disaster recovery practice deleting table , restoring in cassandra via snapshot on test cluster have built.

this test cluster has 4 nodes, , used node restart method after truncating table in question, nodes shutdown, commitlog directories cleared, , current snapshot data copied table directory each node. afterwards, brought each node up. following documentation ran repair on each node, followed refresh on each node.

my question is, why necessary me run repair on each node afterwards assuming none of nodes down except when shut them down perform restore procedure? (in test instance small amount of data , took little time repair, if happened in our production environment repairs take 12 hours perform huge issue in disaster scenario).

and assume running repair unnecessary on single node instance, correct?

just trying figure out purpose of running repair , subsequent refresh is.

what repair?

repair 1 of cassandra's main anti-entropy mechanisms. ensures nodes have latest version of data. reason takes 12 hours (this normal way) is expensive operation -- io , cpu intensive -- generate merkel trees data, compare them merkel trees other nodes, , stream missing / outdated data.

why run repair after restoring snapshots

repair gives consistency baseline. example: if snapshots weren't taken @ exact same time, have chance of reading stale data if you're using cl 1 , hit replica restored older snapshot. repair ensures replicas date latest data available.

tl;dr:

repairs take 12 hours perform huge issue in disaster scenario).

while repair running, you'll have risk of reading stale data if snapshots don't have same exact data. if old snapshots, gc_grace may have passed tombstones giving higher risk of zombie data if tombstones aren't propagated across cluster.

related side rant - when run repair?

the coloquial definition of term repair seems imply system broken. think "i have run repair? must have done wrong un-repaired state!" not true. repair normal maintenance operation cassandra. in fact, should running repair @ least every gc_grace seconds ensure data consistency , avoid zombie data (or use opscenter repair service).

in opinion, should have called antientropymaintenence or cassandraoilchange or rather repair : )


Comments

Popular posts from this blog

java - Spring Data JPA: Why findOne(id) executing delete query internally? -

python - Mongodb How to add addtional information when aggregating? -

java - Incorrect order of records in M-M relationship in hibernate -