You are right that there is no un-available time during the membership
change. I just have tested it using
RaftReconfigurationBaseTest.testBootstrapReconfWithSingleNodeAddOne() as
below.
*+++
b/ratis-server/src/test/java/org/apache/ratis/server/impl/RaftReconfigurationBaseTest.java*
@@ -352,9 +352,15 @@ public abstract class
RaftReconfigurationBaseTest<CLUSTER extends MiniRaftCluste
clientThread.start();
if (!startNewPeer) {
- final TimeDuration delay = FIVE_SECONDS;
- LOG.info("delay {} and start new peer(s): {}", delay,
c1.newPeers);
- delay.sleep();
+ final int delayInSeconds = 5;
+ LOG.info("delay {}s and start new peer(s): {}", delayInSeconds,
c1.newPeers);
+ for (int i = 0; i < delayInSeconds; i++) {
+ final SimpleMessage message = new SimpleMessage("async" + i);
+ final RaftClientReply reply =
client.async().send(message).get();
+ LOG.info("Received reply {} for {}", reply, message);
+ Assert.assertTrue(reply.isSuccess());
+ ONE_SECOND.sleep();
+ }
for(RaftPeer p : c1.newPeers) {
cluster.restartServer(p.getId(), true);
}
Hope it helps.
Tsz-Wo
On Wed, Feb 3, 2021 at 3:30 PM GlenGeng <[email protected]> wrote:
>
>
> Hi all,
>
>
> I have a question about the membership change implemented by Ratis.
>
>
> Ratis implements the joint consensus (the complex one, according to the
> add/remove one server each time), and use LeaderStateImpl#stagingState to
> maintain the catch up progess of the new added raft node, thus won't append
> the OldNewConf into raft log until the new added peer catch up.
>
>
> I consider there should be no un-available time during the membership
> change theoriocitally, even trying to change a single node cluster to a two
> node cluster, is that right ?
>
>
> Thanks!
> BR Glen
>
>
