etcd leader selection

148 views
Skip to first unread message

jesse

unread,
Jun 13, 2014, 1:55:01 PM6/13/14
to etcd...@googlegroups.com
I set up a cluster of two hosts A and B. A is the leader and B is the slave.

 - on host B, curl -L http://127.0.0.1:4001/v2/leader shows host A  as leader.
 - now I shutdown etcd process @ host A. 
 - etcd process @ host B shows: leader changed from 'host-A' to ""
 - query leader o host B turns error.

if my understanding is correct, host B should turn into leader automatically. is this a bug?


Xiang Li

unread,
Jun 13, 2014, 1:59:39 PM6/13/14
to jesse, etcd...@googlegroups.com
B should not turn into leader. 

You have a two node cluster. The quorum is 2 (floor(N/2) + 1), which means the cluster can only be available when all the nodes are running properly. 


--
You received this message because you are subscribed to the Google Groups "etcd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to etcd-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jesse

unread,
Jun 13, 2014, 4:28:29 PM6/13/14
to etcd...@googlegroups.com, chat2...@gmail.com
Your are right, A new leader is re-selected if the scenarios is played against 3 nodes.

I understand the quorum is (floor(N/2) + 1)  is followed. However, why 2 nodes cluster can not be handled for a special case? many simple services are composed of only 2 nodes.  and we hope the slave can continue to serve traffic if the master dies.

thanks!

-jesse 

Thomas Kula

unread,
Jun 13, 2014, 5:27:45 PM6/13/14
to etcd...@googlegroups.com, jesse
Because it's unsafe to do so. What happens if both A and B come up at
the same time but cannot talk to each other, but can talk to clients?
In your scenario both think they are the leader and will accept changes,
which gets you in a state that etcd is explicitly designed to prevent.
Etcd and the raft algorithm it is based on are designed specifically so
there is one and only one view of the world.

On Fri, Jun 13, 2014 at 01:28:29PM -0700, jesse wrote:
> Your are right, A new leader is re-selected if the scenarios is played
> against 3 nodes.
> I understand the quorum is (floor(N/2) + 1) is followed. However, why
> 2 nodes cluster can not be handled for a special case? many simple
> services are composed of only 2 nodes. and we hope the slave can
> continue to serve traffic if the master dies.
> thanks!
> -jesse
> On Friday, June 13, 2014 10:59:39 AM UTC-7, xiang.li wrote:
>
> B should not turn into leader.
> You have a two node cluster. The quorum is 2 (floor(N/2) + 1), which
> means the cluster can only be available when all the nodes are running
> properly.
>
> On Fri, Jun 13, 2014 at 10:55 AM, jesse <[1]chat2...@gmail.com> wrote:
>
> I set up a cluster of two hosts A and B. A is the leader and B is the
> slave.
> - on host B, curl -L [2]http://127.0.0.1:4001/v2/leader shows host A
> as leader.
> - now I shutdown etcd process @ host A.
> - etcd process @ host B shows: leader changed from 'host-A' to ""
> - query leader o host B turns error.
> if my understanding is correct, host B should turn into leader
> automatically. is this a bug?
>
> --
> You received this message because you are subscribed to the Google
> Groups "etcd-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to [3]etcd-dev+u...@googlegroups.com.
> For more options, visit [4]https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "etcd-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [5]etcd-dev+u...@googlegroups.com.
> For more options, visit [6]https://groups.google.com/d/optout.
>
> References
>
> 1. javascript:/
> 2. http://127.0.0.1:4001/v2/leader
> 3. javascript:/
> 4. https://groups.google.com/d/optout
> 5. mailto:etcd-dev+u...@googlegroups.com
> 6. https://groups.google.com/d/optout

--
Thomas L. Kula | ku...@tproa.net | http://kula.tproa.net/

jesse

unread,
Jun 13, 2014, 8:35:14 PM6/13/14
to Thomas Kula, etcd...@googlegroups.com

But in reality, most time we always have good networking connection : A and B can communicate each other even they are started at the same time.  Thus i believe etcd should be able to further improve leader selection for 2 nodes. Correct me if i am wrong.

You received this message because you are subscribed to a topic in the Google Groups "etcd-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/etcd-dev/2kKGD3kMfpE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to etcd-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jesse

unread,
Jun 13, 2014, 8:44:47 PM6/13/14
to Thomas Kula, etcd...@googlegroups.com

Never mind, i think i am wrong. What i can do is spawn 2 etcd instances in one host. 

Thomas Kula

unread,
Jun 13, 2014, 9:19:18 PM6/13/14
to etcd...@googlegroups.com, jesse
The problem there is you're not gaining anything --- if you launch two
etcd instances on host A and one on host B, and host A fails, you've
still lost quorum, because 2 out of the 3 etcd instances are not
running.

On Fri, Jun 13, 2014 at 05:44:46PM -0700, jesse wrote:
> Never mind, i think i am wrong. What i can do is spawn 2 etcd instances
> in one host.Ā
>
> On Jun 13, 2014 5:35 PM, "jesse" <[1]chat2...@gmail.com> wrote:
>
> But in reality, most time we always have good networking connection
> : A and B can communicate each other even they are started at the
> same time.Ā Thus i believe etcd should be able to further improve
> leader selection for 2 nodes. Correct me if i am wrong.
>
> On Jun 13, 2014 2:27 PM, "Thomas Kula" <[2]ku...@tproa.net> wrote:
>
> Because it's unsafe to do so. What happens if both A and B come up
> at
> the same time but cannot talk to each other, but can talk to
> clients?
> In your scenario both think they are the leader and will accept
> changes,
> which gets you in a state that etcd is explicitly designed to
> prevent.
> Etcd and the raft algorithm it is based on are designed specifically
> so
> there is one and only one view of the world.
> On Fri, Jun 13, 2014 at 01:28:29PM -0700, jesse wrote:
> > Ā Ā Your are right, A new leader is re-selected if the scenarios
> is played
> > Ā Ā against 3 nodes.
> > Ā Ā I understand the quorum is (floor(N/2) + 1) Ā is followed.
> However, why
> > Ā Ā 2 nodes cluster can not be handled for a special case? many
> simple
> > Ā Ā services are composed of only 2 nodes. Ā and we hope the
> slave can
> > Ā Ā continue to serve traffic if the master dies.
> > Ā Ā thanks!
> > Ā Ā -jesse
> > Ā Ā On Friday, June 13, 2014 10:59:39 AM UTC-7, [3]xiang.li
> wrote:
> >
> > Ā Ā B should not turn into leader.
> > Ā Ā You have a two node cluster. The quorum is 2 (floor(N/2) +
> 1), which
> > Ā Ā means the cluster can only be available when all the nodes
> are running
> > Ā Ā properly.
> >
> > Ā Ā On Fri, Jun 13, 2014 at 10:55 AM, jesse
> <[1][4]chat2...@gmail.com> wrote:
> >
> > Ā Ā I set up a cluster of two hosts A and B. A is the leader and
> B is the
> > Ā Ā slave.
> > Ā Ā - on host B, curl -L [2][5]http://127.0.0.1:4001/v2/leader
> shows host A
> > Ā Ā as leader.
> > Ā Ā - now I shutdown etcd process @ host A.
> > Ā Ā - etcd process @ host B shows: leader changed from 'host-A'
> to ""
> > Ā Ā - query leader o host B turns error.
> > Ā Ā if my understanding is correct, host B should turn into
> leader
> > Ā Ā automatically. is this a bug?
> >
> > Ā Ā Ā --
> > Ā Ā Ā You received this message because you are subscribed to
> the Google
> > Ā Ā Ā Groups "etcd-dev" group.
> > Ā Ā Ā To unsubscribe from this group and stop receiving emails
> from it,
> > Ā Ā Ā send an email to [3][6]etcd-dev+u...@googlegroups.com.
> > Ā Ā Ā For more options, visit
> [4][7]https://groups.google.com/d/optout.
> >
> > Ā Ā --
> > Ā Ā You received this message because you are subscribed to the
> Google
> > Ā Ā Groups "etcd-dev" group.
> > Ā Ā To unsubscribe from this group and stop receiving emails from
> it, send
> > Ā Ā an email to [5][8]etcd-dev+u...@googlegroups.com.
> > Ā Ā For more options, visit
> [6][9]https://groups.google.com/d/optout.
> >
> > References
> >
> > Ā Ā 1. javascript:/
> > Ā Ā 2. [10]http://127.0.0.1:4001/v2/leader
> > Ā Ā 3. javascript:/
> > Ā Ā 4. [11]https://groups.google.com/d/optout
> > Ā Ā 5. mailto:[12]etcd-dev+u...@googlegroups.com
> > Ā Ā 6. [13]https://groups.google.com/d/optout
> --
> Thomas L. Kula | [14]ku...@tproa.net | [15]http://kula.tproa.net/
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "etcd-dev" group.
> To unsubscribe from this topic, visit
> [16]https://groups.google.com/d/topic/etcd-dev/2kKGD3kMfpE/unsubscri
> be.
> To unsubscribe from this group and all its topics, send an email to
> [17]etcd-dev+u...@googlegroups.com.
> For more options, visit [18]https://groups.google.com/d/optout.
>
> References
>
> 1. mailto:chat2...@gmail.com
> 2. mailto:ku...@tproa.net
> 3. http://xiang.li/
> 4. mailto:chat2...@gmail.com
> 5. http://127.0.0.1:4001/v2/leader
> 6. mailto:etcd-dev%2Bu...@googlegroups.com
> 7. https://groups.google.com/d/optout
> 8. mailto:etcd-dev%2Bunsu...@googlegroups.com
> 9. https://groups.google.com/d/optout
> 10. http://127.0.0.1:4001/v2/leader
> 11. https://groups.google.com/d/optout
> 12. mailto:etcd-dev%2Bunsu...@googlegroups.com
> 13. https://groups.google.com/d/optout
> 14. mailto:ku...@tproa.net
> 15. http://kula.tproa.net/
> 16. https://groups.google.com/d/topic/etcd-dev/2kKGD3kMfpE/unsubscribe
> 17. mailto:etcd-dev%2Bunsu...@googlegroups.com
> 18. https://groups.google.com/d/optout
Reply all
Reply to author
Forward
0 new messages