Hi Alexey, First of all, does your application need multi-Raft, i.e. multiple Raft groups? For the single group case (non-multi-Raft), we should build the servers with the group but not using addGroup.
As specified in the javadoc of GroupManagementApi, addGroup is an operation applying to a particular server; see [1]. You may take a look at GroupManagementBaseTest [2]. Hope it helps! Please feel free to let us know if you have more questions Tsz-Wo [1] https://github.com/apache/ratis/blob/65fd4445335d0500fd372f37c8b7cb3c39259e87/ratis-client/src/main/java/org/apache/ratis/client/api/GroupManagementApi.java#L29 [2] https://github.com/apache/ratis/blob/master/ratis-server/src/test/java/org/apache/ratis/server/impl/GroupManagementBaseTest.java On Fri, May 16, 2025 at 10:44 AM Alexey Goncharuk < [email protected]> wrote: > Hello Ratis community, > > I am trying to understand what is the proper way to initialize a Ratis > group. My expectation is that the group itself should maintain the list of > peers through configuration changes and the raft log, and thus setting the > list of peers is required only during the initial group setup. However, > what I observe in tests is that the initial list of peers passed to > addGroup request is restored only when the corresponding configuration > change has been committed by Ratis. More specifically, I see the following > behavior: > * Create a Raft server S1, initialize a group G1 [peers: S1. S2]. I get a > reply that the group was successfully added, but the configuration change > is not committed because S2 does not exist and thus no leader can be elected > * I stop the server S1 and then restart it with RECOVERY startup option. > The group G1 is restored, but it is restored with the empty peers list > > I was wondering whether this is an expected behavior? I fully understand > that subsequent configuration changes must go through regular raft > protocol, but I would expect that the initial configuration setup is > 'committed' unconditionally and can be reset with the FORMAT startup option > if required. > If this is an expected behavior, I was wondering what is the suggested way > to do the initial group setup? The potential issue I have in mind is as > follows: let's say I am setting up a 3-node cluster with a proper initial > configuration, and addGroup request succeeds on all nodes, but shortly > after one of the nodes gets disconnected and restarted. The two remaining > nodes will be able to commit the proposed configuration, however, the third > node will restart with an empty peers list, so it will require another > addGroup request to join the cluster. Or am I missing something? > > Thank you, > Alexey >
