java ClockRepair_cassandra日常维护之nodetool repair

前提

cassandra的根据分区key的操作是很快的，这也是它的优势，但是它的多条件查询是很弱的，特别是如果你有删除操作的话，就更坑爹了。cassandra的删除操作，实际上并不是真的删除，它是执行的插入操作，插入的数据叫做tombstone(墓碑)，记录了被删除记录的信息和删除时间。当你根据条件查询的时候，如果它会把满足条件的记录查询出来，包括tombstone。然后过滤掉删除的记录，再把结果返回给你。

现象

如果你的表mykeyspace.t_table有3个副本，主键是(a,b,c) 。你插入4000条数据(a=1)，然后再删除掉3999条，你再根据a=1去查询，你会在cassandra的日志中发现一条警告日志.

WARN [ReadStage:18926] 2015-02-05 07:18:02,869 SliceQueryFilter.java Read 1 live and 11997 tombstoned cells in mykeyspace.t_table (see tombstone_warn_threshold)....

这个警告信息是根据你的cassandra.yaml里配置的tombstone_warn_threshold决定的。也就是说它搜索了11997=3999*3条数据，才搜到一个1个live。这就是墓碑的危害。当你删除的数据更多的时候。到达配置项tombstone_failure_threshold的值，这次查询就失败了。你会看到下面的ERROR日志。

ERROR [ReadStage:219774] 2015-02-04 00:31:55,713 SliceQueryFilter.java (line 200) Scanned over 100000 tombstones in mykeyspace.t_table; query aborted (see tombstone_fail_threshold)

ERROR [ReadStage:219774] 2015-02-04 00:31:55,713 CassandraDaemon.java (line 199) Exception in thread Thread[ReadStage:219774,5,main]

java.lang.RuntimeException: org.apache.cassandra.db.filter.TombstoneOverwhelmingException

at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1916)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:745)

Caused by: org.apache.cassandra.db.filter.TombstoneOverwhelmingException

at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:202)

真实的数据实实在在的被删除，发生在两个时期：

第一个时期是新的SSTable文件生成的时候。而且它只删除gc_grace_seconds之前插入的tombstone。

gc_grace_seconds是表结构的一个额外参数，可以通过alter table进行修改。所以说如果你的某个节点挂了，挂的时间超过gc_grace_seconds。可能导致删除的数据又出现了。

第二个时期就来自日常的Nodetool repair操作。每个gc_grace_seconds周期内至少repair一遍。

解决

普通repair

nodetool repair基本语法是这样的：

nodetool -h host repair [keyspace] [cfnames]

它会修复keyspace.cfnames这个表分区主键token值落在这个节点上的数据(包括master和slave数据)。等你把所有的节点repair一遍，

如果你有三个副本，你相当于repair了三遍数据，所以这个时间会很长。

只repair master数据

你可以使用-pr选项，表示只修复range落在该节点的master数据：当然你需要把所有的节点都repair一遍。

nodetool -h host -pr repair [keyspace] [cfnames]

根据token段repair

当你的数据量足够大的时候，这个过程还是很慢，你可能焦急的不知道这个过程什么时候结束。你可以通过token段的方式，

nodetool -h host -st xxx -et xxxx repair [keyspace] [cfnames]

至于token段的获取，可以使用nodetool ring命令得到。

Note: Ownership information does not include topology; for complete information, specify a keyspace

Datacenter: datacenter1

==========

Address Rack Status State Load Owns Token

9192997390010868737

192.168.1.101 rack1 Up Normal 98.1 MB 35.79% -9196740398802827883

192.168.1.102 rack1 Up Normal 98.55 MB 30.03% -9124289757510820389

192.168.1.103 rack1 Up Normal 98.09 MB 34.18% -9088595326201594476

192.168.1.102 rack1 Up Normal 98.55 MB 30.03% -9084487345633494070

192.168.1.101 rack1 Up Normal 98.1 MB 35.79% -9061596030643872312

192.168.1.102 rack1 Up Normal 98.55 MB 30.03% -9056941391849010003

192.168.1.101 rack1 Up Normal 98.1 MB 35.79% -9055818090063560183

这就表示token 从-9088595326201594476到-9084487345633494070的master数据分布在192.168.1.102机器上。

多线程并发repair。

可以加一个-par选项 例如：

nodetool -h host -pr -par repair [keyspace] [cfnames]

nodetool -h host -st xxx -et xxxx -par repair [keyspace] [cfnames]

这个repair速度会提高数倍。但是你要考虑你集群的负载。

增量repair

可以加一个-inc选项(注:这个选项只能在2.1以后的版本使用)

例如

每条数据都有自己的时间戳，当你repair一次之后，你第二次repair的时候，其实只要repair上次repair数据最后一个时间戳之后的数据就可以了。

nodetool -h host -pr -inc repair [keyspace] [cfnames]

nodetool -h host -st xxx -et xxxx -inc repair [keyspace] [cfnames]

这样也可以增加repair速度，注意-inc和-par是不能一起使用的。