Hi, Xiangdong, So what your suggestions about the election waiting time? Add another configuration parameter called election_wait_time_ms, or left as a shorter hardcode constant?
发件人: Eric Pai <[email protected]> 日期: 2021年8月21日 星期六 下午7:32 收件人: "[email protected]" <[email protected]> 主题: 回复: Conclusion about JIRA issue[IOTDB-1564]: Make leader failure detection and election faster Hi, all, Now the randomElectionWait time is hardcode as 3-5s, which is not suitable when the heartbeat_interval_ms and election_timeout_ms is too small. I decide to change it to [2* heartbeat_interval_ms, 2* heartbeat_interval_ms + 50ms). The 50ms is referred from the Raft paper with a low probability and fast election when split votes happens. But I haven’t found any detailed descriptions about the relationship between heartbeat_interval_ms and the least waiting time. Any good suggestions? 发件人: 白 渐 发送时间: 2021年8月18日 22:14 收件人: [email protected] 主题: Conclusion about JIRA issue[IOTDB-1564]: Make leader failure detection and election faster Hi, all, @Xinyu Tan and me have made a conclusion about the refine of hearbeat and election related timeout parameters: JIRA link: https://issues.apache.org/jira/browse/IOTDB-1564 Two parameters are added: heartbeat_interval_ms (t1): The time interval(ms) between two rounds of heartbeat broadcast of one raft group leader. election_timeout_ms (t2 and t3): The election timeout time of candidates and followers, or as the parameter of waiting for voting result. t1 t1 Leader view: Send HB - - -> Send HB - - -> Send HB t2 t3 Follower view: Receive HB - - -> Receive HB - - - - -> HB expired / Start election - - - - -> Election Timeout I will do the following works sooner or later: 1. Coding. 2. Proper test cases. 3. Docs about new parameters. Thanks.
