> This attribute seems to be only modified when executing "nodetool repair > [keyspace] [table....]", but not when executing with other options like > --in-local-dc or --pr.
This is correct behavior because this metric actually represent the percentage of SSTables incrementally repaired - and marked as repaired - which doesn't happen when you execute a non-incremental repair (--full, --in-local-dc, --pr). When you perform a non-incremental repair data is repaired but not marked as repaired since this require anti-compaction to be run. Actually this "percent repaired" display name is a bit misleading, since it sounds like data needs to be repaired while you could be running non-incremental repairs and still have data 100% repaired, so we should probably open a ticket to rename that to "Percent incrementally repaired" or similar. 2017-06-22 14:38 GMT-05:00 Javier Canillas <javier.canil...@gmail.com>: > Hi, > > I have been thinking about scheduling a daily routine to force repairs on a > cluster to maintain its health. > > I saw that by running a nodetool tablestats [keyspace] there is an attribute > called "Percent repaired" that show the percentage of data repaired on the > each table. > > This attribute seems to be only modified when executing "nodetool repair > [keyspace] [table....]", but not when executing with other options like > --in-local-dc or --pr. > > My main concern is about building the whole MERKLE tree for a big table. I > have also check to repair by token ranges, but this also seems not to modify > this attribute of the table. > > Is this an expected behavior? Or there is something missing on the code that > needs to be fixed? > > My "maintenance" script would be calling nodetool tablestats per each > keyspace that has replication_factor > 0 to check for the value of the > "Percent repaired" of each table and, in case it is below some threshold, I > would execute a repair on it. > > Any ideas? > > Thanks in advance. > > Javier. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
