Zhangyi Chen
Zhangyi Chen
看下 /raft_stat页面。 超时看起来是卡住了。 不然客户端会立即收到不是leader的错误。
pstack下，这种应该就是卡死了
能构造ut去复现么?
数据会变化吗?
hostname和ip的对应关系能保证一致性么. 一个方案是peerid支持naming service，但是这样查询ip肯定就不是实时生效了。有两个问题: 1. 节点重启到发现恢复需要的时间会更长 2. 这里可能存在ABA问题(比如两个节点同时重启，ip互换). 2018-04-19 14:16 GMT+08:00 Peng Du : > 数据不变，不如数据存在EBS或者EFS里面。 > > 但是k8s里面重启pod/container之后，IP是会变的，这样起来后，braft会需要重新set peers，然后还是会同步所有的数据。 > > 期望是，用k8s的stateful部署，这样可以做到hostname不变但是IP还是会变，在braft里面用hostname去标记所有的meta， > 这样pod/container重启之后就不用重新同步数据了。 > > — > You are...
支持hostname并不难，让braft::PeerId适配下就好了，现在所有的传输和存储格式都是string，这不会带来兼容性问题。 另外 brpc::Channel是支持动态更新hostname到ip的映射. 但是更新会有一点delay（主动refresh）. 这里主要还是得确认几点; 1. hostname会不会查出多个ip 2. ip在多少时间内不会被重用. 2018-04-19 15:01 GMT+08:00 Peng Du : > 不能保证。k8s的stateful只能保证每次重启hostname不变，但是IP是不做限制的（刚被释放的IP，是否会被立即重用， > 这个我不确定，但是我感觉应该会有限制，待确认）。 > > 我现在简单的改了一个版本： > 1，peerID里面不用butil::EndPoint，自己用hostname + port来代替 > 2，建立braft::Channel的时候，把hostname+port再转换成butil::EndPoint > >...
@pdu 现在没有k8s的测试环境， 你的改动如果比较成熟了，欢迎提交PR，或者可以发起更多的讨论. @lingji 根据我们之前的经验， 『即时聊天』并不是一个非常高效的途径
这个更适合改raft的PeerId 而不是Endpoint On Thu, May 10, 2018 at 4:50 PM, Peng Du wrote: > @chenzhangyi @ipconfigme > 谢谢你们的建议。我也是觉得在brpc:EndPoint中支持更好。 > > 我现在是计划在项目中用braft，等改动成熟了，我来提交PR。 > > — > You are receiving this because...
Deleting all data from a follower and re-join it to the cluster is a very dangerous operation, The empty follower may vote to a wrong leader since any of others...
> > or even worse - purge committed data silently. > > @chenzhangyi > > how is this happend? for the performance reasons, is it saft to use MemoryLogStorage option...