doc001
doc001
> @PFZheng emming, 其实还有一点儿疑惑，client发送一个请求，Leader在响应之前崩了，如果client重试请求，那么这个请求会不会被重复处理？因为leader未响应，如果确定上一次请求是否被成功执行，已经重试的请求是否是重复执行？ 这个是业务需要解决的幂等性问题，本身 braft 没有办法判断请求是否重复，业务可以将用于判断幂等性的信息一并写入日志，利用这些信息来判断是否重复
看这个提示错误，应该是找不到snappy库
第二次启动的时候c的initial_conf指定了自己？ initial_conf 只建议在第一个副本上使用，指向自己，其它新加的副本不应该填该参数，保持空，完全靠 add_peer 来补充。initial_conf 无论持久化与否，对使用者都是一个负担，极容易出问题。
暂时没有群，有问题都是直接在github上交流的，你可以发下你的微信号到我的邮箱：[email protected] (github 啥时候能支持一个聊天的功能) 开源的 braft 其实缺失了一部分，就是 multi-raft 的集群管理程序，需要解决你所列举的这些节点管理和副本管理的问题。这部分公司内的业务都按照自己的需求做了，和业务耦合得比较深，所以短期内没有合适的开源选项。 可以参考下一些基于 braft 的开源项目，他们也都面临这些问题： https://github.com/baidu/BaikalDB https://github.com/opencurve/curve
这个机制看着和 witness 是一回事情，实现得有一些问题： 1. patch 里区分 arbiter 的做法过于粗暴 2. arbiter 不能简单的挡掉住所有的选主，这个节点有可能是一些日志的唯一副本（3副本里，arbiter数据比另外一个follower新），正确的做法是如果必须成为主之后走一轮 tranfer leader 3. snapshot 要特殊处理，保留的 log 能连上所有有效节点的日志（避免成为主之后不能让日志保持连续造成数据丢失） MongoDB 实现的不是标准 Raft，有一些设计不能原样照搬
需要确认下缺失的那一行在干什么（==58110== by 0x7C8262B0: ???），do_committed 主要的工作是回调用户提供的 on_apply 接口
> 想请问一下，目前在pipeline特性的代码中，follower只有当request携带的prev_log_term和本地的local_prev_log_term不同的时候才调用handle_out_of_order_append_entries缓存乱序到达的日志，为什么仅在这种情况下才做缓存处理呢？是否应该在term不变的时候也处理乱序到达的entries呢？ term相等说明请求能和已有的连续日志接上或者有重叠
> > > 想请问一下，目前在pipeline特性的代码中，follower只有当request携带的prev_log_term和本地的local_prev_log_term不同的时候才调用handle_out_of_order_append_entries缓存乱序到达的日志，为什么仅在这种情况下才做缓存处理呢？是否应该在term不变的时候也处理乱序到达的entries呢？ > > > > > > term相等说明请求能和已有的连续日志接上或者有重叠 > > term相同应该只是没有换选吧，但是还是有可能出现乱序到达的日志的吧，比如客户端一段时间没有进行操作，之后突然又恢复了业务，会连续发出多条request，这时不是有可能会乱序么？ 是有可能乱序，但是不是每个情况下都需要走handle_out_of_order_append_entries路径，例如，原来本地的log index到 4了，并发过来的是 5,6,7。如果5先处理就不是out of order，反之，如果6、7先处理就需要handle_out_of_order_append_entries
盘上的数据没有问题？
> 另外还有一个现象 正常运行时即使没有发生leader切换，也会时不时打一些 reject term_unmatched 的日志，来自leader的AppendEntries的请求。 > > > > > [2022-01-03 11:22:19.361114] [WARNING] [110087] [external/com_github_brpc_braft/src/braft/node.cpp:2443] :node kv:11.53.255.151:7764:0 reject term_unmatched AppendEntries from 11.53.255.85:7764:0 in term 120 prev_log_index 98017631735 prev_log_term 120...