Got it, thanks! If there is a documentation page I can update (unless this info is already there and I missed it), I'll be happy to summarize this.
вт, 20 мая 2025 г. в 18:51, Tsz-Wo Nicholas Sze <[email protected]>: > Hi Alexey, > > > No, I do not need multi-raft. ... > > For non-multi-raft, just build the RaftServer with the group. We need to > FORMAT it the first time and then keep using RECOVER. > > > ... the builder accepts a group during construction, but it also accepts > the RECOVER startup option. ... > > When a server starts, it will use the group id in the specified group to > read the corresponding local directory. Then, it either formats (creates a > new directory) or recovers from an existing directory. > > For RECOVER, it reads the latest group information from the local > storage. You are right that the group peers passed to the builder will be > ignored. Only the group id is used. > > Tsz-Wo > > > > > On Mon, May 19, 2025 at 2:18 AM Alexey Goncharuk < > [email protected]> wrote: > >> 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 >>>> >>>
