-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lab4B push or pull #23
Comments
按照这个 case 应该是 A 必须得持久化之后再返回接收成功,否则 B 就不能在这个时候自增 configNum |
万分感谢! |
不是很明白,configNum = 1时, 当B push数据给A,Group A的leader接收到push来的数据之后,不是会先交给raft进行group内复制吗,同样,当A宕机重启后,之前push来的数据还在raft的log里,接着重放log内的数据就行了,为什么会一直阻塞呢? |
你说的是对的。的确是交由raft层达成一致(持久化)后,才能算作接收数据成功,然后再给B回复RPC消息。 |
博主您好!关于分片迁移的push模式我想问一下,以下这种case是如何解决的,是否会发生呢?groupA和groupB在ConfigNum为1时,B需要发送shard数据给A,并且A接收成功,B发送成功了,然后A和B正常运行到达了更高的ConfigNum,之后若A在没有persist数据时宕机重启了,ConfigNum重置为0了,当它再次到达ConfigNum为1时,是否会一直阻塞在此呢,因为B已经不会再给它发送数据了。换句话说,ConfigNum是否需要连续递增?能否直接query到高版本的Config,然后进行数据迁移?
The text was updated successfully, but these errors were encountered: