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,这样这条被删除的数据会被恢复出来。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180222G132OC00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券