Hi Tsz-Wo, thanks for the reply! No, I do not need multi-raft. I saw the server builder, however I am a bit confused regarding building the server. I see that the builder accepts a group during construction, but it also accepts the RECOVER startup option. Given that there is no way to understand the last committed configuration unless the server is started, does it mean that the group passed to the server builder should be treated as a 'bootstrap' group and it is ignored when server recovers and knows that there was a group reconfiguration?
--Alexey сб, 17 мая 2025 г. в 21:19, Tsz-Wo Nicholas Sze <[email protected]>: > 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 >> >
