关于Titan实现中LogAndApply失败处理的实现问题

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:master分支
  • 【问题描述】:
    我不确定提到这里是否合适,如果不合适麻烦告知应该发在哪,多谢。
    我在github titan上提了一个issue,主要是想交流、确认下我分析的情况是否会是一个bug。

场景是我看到当Titan在LogAndApply VersionEdit失败后,会让titan进入read only状态,此时主要是通过设置bg_error_以及has_bg_error_这个flag。 后续接口调用上,都会判断has_bg_error_是否为true,进而在为true是,阻止用户的后续put/write操作。

但是代码实现上, has_bg_error_的判断逻辑(HasBGError())中,并没有hold锁来判断has_bg_error_,而是直接依靠has_bg_error_的原子性来完成,has_bg_error_自身的原子性是没有问题的, 但我想到的场景是,因为HasBGError()判断时,没有hold锁,当LogAndApply实际已经失败,且bg_error_已经被设置,但是has_bg_error_还没来得及设置,此时,HasBGError()仍然会返回false,进而,用户方的Put/Write会被放过,继续执行,而如果此时进一步的引起Compaction,出发后续的BlobFileSet上的LogAndApply,则会使得在一个已经出错的状态下,进一步apply错误的信息, 进而导致一些非预期的行为

LogAndApply失败,可能是manifest写入出了问题,此时,可能writer已经设置为error了,此时还好说,如果是VersionStorage上的一些校验出问题,例如stoarge->MarkFileObsolete(…)等,是否会引起后续一些非预期的行为。

这种处理是否是bug,HasBGError()应该带锁进行判断?

已在GitHub issue中回复

收到,多谢。