Ian; to respond to your specific question: You could pipe the output of your repair into a file and subsequently determine the time taken. example: nodetool repair -dc DC1 [2014-07-24 21:59:55,326] Nothing to repair for keyspace 'system' [2014-07-24 21:59:55,617] Starting repair command #2, repairing 490 ranges for keyspace system_traces (seq=true, full=true) [2014-07-24 22:23:14,299] Repair session 323b9490-137e-11e4-88e3-c972e09793ca for range (820981369067266915,822627736366088177] finished [2014-07-24 22:23:14,320] Repair session 38496a61-137e-11e4-88e3-c972e09793ca for range (2506042417712465541,2515941262699962473] finished What to look for: a) Look for the specific name of the Keyspace & the word 'starting repair'b) Look for the word 'finished'. c) Compute the average time per keyspace and you would be able to have a rough idea of how long your repairs would take on a regular basis. This is only for continual operational repair, not the first time its done. hope this helpsJan/
On Thursday, March 19, 2015 12:55 PM, Paulo Motta <pauloricard...@gmail.com> wrote: From: http://www.datastax.com/dev/blog/modern-hinted-handoff Repair and the fine print At first glance, it may appear that Hinted Handoff lets you safely get away without needing repair. This is only true if you never have hardware failure. Hardware failure means that - We lose “historical” data for which the write has already finished, so there is nothing to tell the rest of the cluster exactly what data has gone missing - We can also lose hints-not-yet-replayed from requests the failed node coordinated With sufficient dedication, you can get by with “only run repair after hardware failure and rely on hinted handoff the rest of the time,” but as your clusters grow (and hardware failure becomes more common) performing repair as a one-off special case will become increasingly difficult to do perfectly. Thus, we continue to recommend running a full repair weekly. 2015-03-19 16:42 GMT-03:00 Robert Coli <rc...@eventbrite.com>: On Thu, Mar 19, 2015 at 12:13 PM, Ali Akhtar <ali.rac...@gmail.com> wrote: Cassandra doesn't guarantee eventual consistency? If you run regularly scheduled repair, it does. If you do not run repair, it does not. Hinted handoff, for example, is considered an optimization for repair, and does not assert that it provides a consistency guarantee. =Rob http://twitter.com/rcolidba -- Paulo Ricardo -- European Master in Distributed Computing Royal Institute of Technology - KTH Instituto Superior Técnico - ISThttp://paulormg.com