Cassandra系列（4）-Repair

不少网友都在问我关于Cassandra Repair的问题，诸如参数配置，如何进行repair。

repair介绍

Cassandra repair 作用就是修复数据的不一致性问题，在分布式环境中，数据为了保障高可用，通常遵循的是最终一致性。所以各个节点的数据有可能出现不一致的问题。repair就是为了解决这个问题

repair机制

Cassandra repair有三种

1. read repair 读修复，针对的维度是column family

发生在读请求时触发的一个后台任务，由read_repair_chance参数控制，默认值是0.1，即10个读请求触发1次修复动作。另外一个参数dclocal_read_repair_chance，这是限定只修复本数据中心，防止跨数据中心数据同步耗时长。

另外如果是DTCS 压缩策略，需要将读修复关闭，因为DTCS要求插入的数据严格按照时间有序。

2. hinted handoff

这个发生在节点down掉后，原本应该写入到该节点的数据会先写到coordinate node，在一定时间窗口内，节点重新up后，有该节点当时写入的数据的coordinate node会将这些数据再写到这个节点上。

3. 手动repair

即使用nodetool工具来进行repair,因为从1,2中的描述我们可以知道是不能完全保证数据的一致性的。

https://docs.datastax.com/en/cassandra/latest/cassandra/tools/toolsRepair.html

那么在生产环境中nodetool repair job如何去执行呢，总不能发现数据不一致了，手动跑一遍吧。

repair 主要分两种，一种全量(full),一种增量(incr)意思很好理解，全量就是扫描merkle tree上的所有节点，增量就是添加了一个标记，已修复的就不再修复了。

两种方式切换时需要额外操作。

从full-incr 需要禁止compaction,跑一遍full repair,然后重启节点，

从incr-full需要清除repair标记，

在4.x之前，

由于repair然后标记时，没有应答机制，常常会有些节点标记失败https://issues.apache.org/jira/browse/CASSANDRA-9143

所以官方是推荐full repair.

定期(一周)跑一次

对于删除频繁的table，周期需要更短。

删除数据时，会发送一个tombstone标记，标记数据被删除，然后在compaciton阶段将数据删除。

如果在发送delete request到节点时，某个拥有该数据的节点down了，Cassandra会一直重新发送。

只要节点在gc_grace_seconds时间内恢复过来，他就会收到delete request。如果节点超过了这个时间。tombstone 就会被gc回收，节点就会丢失删除数据的delete request，这样这条被删除的数据会被恢复出来。