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是不能一起使用的。