不少网友都在问我关于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,这样这条被删除的数据会被恢复出来。
领取专属 10元无门槛券
私享最新 技术干货