You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ratis.apache.org by GlenGeng <gl...@163.com> on 2021/02/03 07:30:18 UTC

Question about membership change (setConfiguration)


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

Re:Re: Question about membership change (setConfiguration)

Posted by GlenGeng <gl...@163.com>.


Thanks @szetszwo for the clarification !



It really helps. Shashi and I went through code yesterday and got the same conclusion, yet not verified.
The setConfiguration implementation rigoriously complies with the joint consensus algorithms, which simplies the design of bootstrap a new empty SCM in the HA mode.


BR Glen




At 2021-02-04 17:33:18, "Tsz Wo Sze" <sz...@gmail.com> wrote:
>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 <gl...@163.com> 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
>>
>>

Re: Question about membership change (setConfiguration)

Posted by Tsz Wo Sze <sz...@gmail.com>.
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 <gl...@163.com> 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
>
>