kill掉一个存储节点后 raft replicate log/append log 延时非常高 平均300ms以上

问答 问题
1

  • nebula 版本：2.6.2

  • 部署方式：分布式

  • 安装方式：源码编译 / Docker / RPM

  • 问题的具体描述

  • 相关的 meta / storage / graph info 日志信息（尽量使用文本形式方便检索）

我在探究一下nebula稳定性的时候 kill掉了某个存储节点 导致hd访问storage超时，存储层replicate log/append log 部分节点出现非常慢 300多ms

2

是比原来慢，还是说这个数据就是一个新数据，你觉得这个数值可以优化下？

3

就是一个写入的任务 在写入过程kill掉一个存储节点 过一会拉回来 这时候需要追数据 raft replicate log/append log慢

4

2.6的raft实现存在诸多问题，建议升级到最新版

5

咱们能不能给解释啥啥原因可能会导致这个问题

6

可以用perf看一下卡在了哪里。

目前一个猜测是：

假设，Peer{A,B,C}，A是Leader，C故障一段时间后拉起。之后A要向BC去append log时，需要知道BC各自的最后一条log id。因为C落后很多，所以A要在wal里一条一条的找（这里是O(n)的）。找到之后才会给BC发送RPC请求。所以怀疑是慢在了找wal

7

对 我研究了一下 a b c三个副本 a是leader bc是follower 假设我将b kill掉2个小时 在拉回来 会出现append log会很慢 同时也会阻塞 每一轮rpc的发送 我这看a 发个b/c的request必须准备好 才能发送。而b因为diff很大 查log慢 导致整个rpc同步的很慢 是这个原因吗？ 如果是 那么最新版本是如何解决的

8

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。