Cassandra User 问题汇总(1)------------repair

Cassandra Repair 问题

问1:

文档建议每周或者每月跑一次full repair.那么如果我是使用partition rangerepair，是否还有必要在cluster的每个节点上定期跑full repair ？

答1:

为什么要定期跑full repair

一般在gc_grace_seconds 间隔时间内跑repair
- 确保集群的数据保持一致。通常节点的write consistency都不会是ALL。所以集群内的数据可能不一致。
以及保证删除的数据不会恢复

• 对down掉的节点修复不一致
  down的节点有可能过了hintedhandoff设置的时间，不会有hintedhandoff message写入。
  数据也有很大的不一致性。

什么是partition range修复

在一个集群里，通常replicator>1.意味着同一份数据在集群内有很多份.如果在每个节点上run repair.
对于同一份数据就会重复repair replicator 次。加上 -pr 参数。就是对于同一range的数据只repair一次。
提高了repair效率。

综上所述，使用partition range repair，仍然有必要定期跑full repair.

问2:

repair 需不需要将一个down 掉的节点移除掉，如果不移除，repair是不是会继续修复其他records

答2:

Cassandra(cassandra 3.x) 目前的做法：

如果replicator =3,集群中共有6个节点，1个节点就有3/6的数据。1/6 的数据是它的token range负责的数据，2/6是他作为replicate的数据。当这个节点down了。有一半的数据replicate=2,这时候run repair 是不会修复这一半的数据的。

深入思考

在上面的回答中可以看出来，因为有多份数据的存在，所以一个node负责的数据占比是很大的。也就是现有的repair会导致很大
一部分数据不能够保持一致。

假如现在一个节点已经down掉10天了，有很多的数据都没有repaired。你也不确定节点什么时候能够修复，需要你做决定了

1.尽早移除节点，然后将节点添加回来

这样会因为token arrangement的重新分配，导致数据在节点间传递。

2.不移除节点,等节点修复好，正常工作

越来越多的数据没有repaired。而且down node时间会超过gc_grace_seconds，这样被删除的数据就会有被恢复的可能。

不去定期做repair，为什么会导致delete data 恢复呢

删除数据时，会发送一个tombstone标记，标记数据被删除，然后在compaciton阶段将数据删除。
如果在发送delete request到节点时，某个拥有该数据的节点down了，Cassandra会一直重新发送。
只要节点在gc_grace_seconds时间内恢复过来，他就会收到delete request。如果节点超过了这个时间。tombstone 就会被gc回收，节点就会丢失删除数据的delete request，这样这条被删除的数据会被恢复出来。

综上两点，我们需要更好的机制去处理repair

jira ticket
https://issues.apache.org/jira/browse/CASSANDRA-10446