Cassandra系列(4)-Repair

原创
2018/02/22 22:33
阅读数 49

不少网友都在问我关于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,这样这条被删除的数据会被恢复出来。


本文分享自微信公众号 - 方丈的寺院(gh_c98f244e174d)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部