副本缺失相关问题

💬 StarRocks 用户问答
#1

【详述】以下所提及的问题都是我在1.19版本时遇到的。现在已升级到2.3版本，我不确定这些问题是否已经得到解决。如果2.3版本或其后续版本已经有了相应的解决方案，请通知我，谢谢。

  1. 关于tablet副本中存在的问题：多副本相互之间存在不交叉或部分交叉（重叠）的情况，导致没有一个副本能够完整，例如在三个副本中，副本A缺少[10-12]版本，副本B缺少[14-16]版本，副本C缺少[18-20]版本。我注意到2.3版本似乎支持通过健康的副本来修复缺失版本的副本，但如果所有副本都是版本不完整的状态，2.3版本如何进行修复？
  2. 在执行base合并操作时，如果在读取base的segment文件过程中发现segment文件丢失，会导致base合并失败。在这种情况下，2.3版本的fe副本修复功能能否修复base的副本？同时，后续的base合并操作能否正常执行？（可能的原因包括segment文件的消失，或者是人为删除。）
  3. 如果数据是三副本，但由于某种未知的原因，三个副本的某个版本全部丢失，这时数据可能已经无法修复。但我仍希望能继续进行查询和compaction操作，否则就会导致报版本超过1000的错误。我注意到有一个名为"recover_with_empty_tablet"的参数，但好像只支持在单副本时进行修复，为什么是这样？在此情况下，我应该如何处理？

【StarRocks版本】例如：2.3

【联系方式】社区群8-tempo

#2
  1. 关于tablet副本 我们推荐线上副本都是3副本最佳，他会分别存储在不同的节点，有一个副本缺失了，那么内部就会去好的副本上clone一份再次进行均衡，三个副本都是不健康的状态下 涉及到调度该tablet的任务就会失败 2. compaction失败之后走的也是第一个逻辑 修复之后再进行合并 3. 第三个是个悖论 都损坏了 不可能在使用了 数据都丢了 1000的限制是导入过程中的1000版本限制 recover_with_empty_tablet是使用空tablet去替代坏的tablet了 也不是修复的方法 只是为了保证查询可用 但不保证查询正确
#3

谢谢您的回复 ,不过这边还有问题

  1. 这边您解释的是如果都不健康 ,所以调度会失败 ,所以就不会修复不健康的副本 ,而我这边问的是 ,不管是不是健康的 ,其实三个副本中 ,是可以找到对应的版本的 ,这个时后是不是可以强制修复? 如果强制修复会有其他问题嘛? 因为听您的回答应该是目前不健康的话,目前没有做修复的功能? 或者如果出现此情况的话 ,官方有其他解决方案吗?
  2. 我这边初步查看源码的理解，可能出错，就是失败这边应该不会走第一个逻辑 ,因为其实meta中版本是一致的 ,但是其实segment文件个数是缺少的 ,所以应该不会走修复?
  3. 场景我可能没说清楚 ,是这样的 , 就是因为已经都损坏了 , 但是由于版本数还有一千的限制 , 所以如果损坏之后没有一个机制可以修复 ,这样后面的数据就无法写入了 ,所以可以跟业务方沟通 ,如果接受有部份数据损坏的话 ,可以使用强制修复方式解决 , 不然连查询都不能使用 , 而recover_with_empty_tablet是目前我看到最接近的解决方案了 ,但也卡在只支持单副本 , 或者是官方有推荐的修复流程解决这问题吗?
#4
  1. 可以的 可以把tablet强制设置成bad 这样内部就会认为他是unhealthy tablet 这样他就会自动修复了
  2. segment级别缺失 这就是文件损坏了 这肯定修复不了的
  3. 版本数还有一千的限制是指哪里 您看的哪块的代码方便发下吗 ？ 我理解是修复的限制？
#5
  1. 可以的 可以把tablet强制设置成bad 这样内部就会认为他是unhealthy tablet 这样他就会自动修复了 ->这边没看懂 , 我指是所有副本都是版本不完整的状态 ,所以已经是unhealthy 了 ,本来就会进行修复 , 但在chooseSrcReplica这边 ,找不到健康的副本 , 就直接UNRECOVERABLE了, 我看的代码是版本2.3
  2. 好的
    3.就是tablet_max_versions ,tablet版本默认1000就无法写入了 ,报Too many versions ,所以如果合并卡住的话 ,就会影响后面写入

另外 , 好像重启时会将rowsetid重置 , 然后starrocks不允许rowsetid重复 , 好像会将文件删除? 不知道是不是造成上面三种随机数据缺失的原因?

#6

1.这种还没遇到过，还有日志吗？正常情况下不糊三个副本都不健康，因为只要两个副本不健康，数据就写不进去了，就需要等待至少两个副本修复。
3.2.4之后的版本支持中间版本丢失，增量合并和base合并都会继续做，不过base合并只会做到丢失版本，之后的只会做增量合并。目前recover_with_empty_tablet这个参数是不生效的应该，出现三个副本都丢失某个版本数据的话，目前只能重新导入对应表或者分区的数据。

#7
  1. 很久了 ,没有日志 。一般情况下的确不会出现，所以怀疑是rowsetid重复被随机删除了
  3. 重新导入对应表或者分区的数据 ,假设是使用kafka ,那就是先把原本那张表的分区全部删除 ,再重新设置kafka那个分区的点重新导入吗?
#8

1.确实没遇到这个问题，另外rowsetid不会变的
3.重新导入数据，把对应分区或者表truncate掉，重新消费kafka数据导入

京ICP备2022026421号-1