Etcd Learning (3) leader problem in cluster building Clustering

Refer to my previous article (Click here) to introduce a key issue in the etcd cluster environment:

Which of the three etcd nodes should be accessed by clustering )???

(1) Any of the three read operations can be performed, even if it is not a leader

(2) For write operations, it seems that only the leader can be connected to write data.

I have a cluster composed of three nodes (127.0.0.1: 4001, 127.0.0.1: 4002, and 127.0.0.1: 4003 ), there is a program that connects to the cluster to enable the timer timed Registration Service (in fact, it is to regularly create a node with TTL), as shown below:

1. String sysflag = "cbip ";
2. Iregistrycenterclient rcenter = registrycenterclientfactory. getregistrycenterclient ();
4. Serviceinfo sinfo1 = new serviceinfo ();
5. Sinfo1.servicename = "helloservice ";
6. Sinfo1.serviceip = "127.0.0.111 ";
7. Sinfo1.serviceport = 1888;
8. Rcenter. registerservice (sinfo1 );
10. While (true)
11. {
12. Console. writeline (rcenter. getconfigitem (sysflag, "configa "));
13. Console. writeline (rcenter. getconfigitem (sysflag, "configb "));
14. Thread. Sleep (200 );
15. }

I connect to the 127.0.0.1: 4001 node in the cluster. At the beginning, the leader of the cluster is 127.0.0.1: 4001. However, over time, the leader may change to 127.0.0.1: 4002 or 127.0.0.1: 4003, I found a conclusion: as long as the leader is 127.0.0.1: 4001, the service can be successfully registered (successfully written to the cluster), as long as the leader is not 127.0.0.1: 4001, the registration will fail! The read configuration items in the loop will remain valid and will not expire as the leader changes.

Q: Why does the leader change over time when I start a cluster with three nodes in this tutorial ???

Then I asked the author this question on etcd's GitHub:

Jiq408694711 commented 13 days ago

Hello:
I have built a cluster of three machines according to this document: https://github.com/coreos/etcd/blob/master/Documentation/clustering.md.

Then I connect to 127.0.0.1: 4001 by etceister and register a service address (actually write service info to etcd node with TTL) by using. Net Timer:

private void KeepAliveTimer(object source, System.Timers.ElapsedEventArgs e){try{if (source != null && source is ServiceInfo){ServiceInfo serviceInfo = source as ServiceInfo;string serviceDir = "service/" + serviceInfo.serviceName;client.CreateDir(serviceDir, 0, false);                string key = serviceDir + "/" + serviceInfo.serviceIP;                string value = JsonSerializer.GetJsonByObject(serviceInfo);                client.Set(key, value, nodeTTL);                logger.Info("[KeepAliveTimer]register success：[key]" + key + ",[value]" + value);                                                }        }        catch (Exception ee)        {            logger.Info("[KeepAliveTimer]register fail：" + ee.Message);        }    }

When I run my code, I find that the output sometimes is "register success", sometimes is "register fail", the reseaon is that the leader of cluster always change by itself, the registeration will fail if the leader is not "127.0.0.1: 4001", the registeration will success if the leader is "127.0.0.1: 4001 ".

I want to know:
(1) Why the leader always keep changing ???
(2) If I want to write to etcd correctly, which active peer I shoshould connect ???
If the correct active peer is Leader, how can I get the leader ???

Thank you !!!

Then the author replied:

Unihorn commented 9 days ago

(1) It is a common case for etcd To Change Leader, though it shoshould not be so frequent.
(2) If you connect to non leader, it will send back a 307 redirect HTTP response, which indicates where the leader is

The author means that the leader in the cluster often changes. If the node (active peer) you connect to is not the leader, a 307 redirection response will be returned, it specifies the leader.

Then I asked again:

Jiq408694711 commented 8 days ago

Thanks
Why the etcd can not redirect my HTTP request to leader automatically? I just need to connect to any peer of the clustering whitout concerning which is the leader

Another author replied:

Jonboulle commented 5 days ago

@ Jiq408694711 for now, honoring the Redirect is the responsibility of the client, and cannot implementations will follow it automatically.

In future, etcd will have a proxy mode which will provide the behaviour you're after.

This means that request redirection is the responsibility of the client... Many implementation solutions will automatically do this !!!

It seems that the C # etcd client I used has not considered this !!!

The author also said that in the future, etcd will use the proxy mode to make up for this.

Etcd is still relatively new and is still under development. Version 1.0 is not available yet. Let's wait and see!

At present, I will not use the cluster for the moment. I should use a node first... Haha

Etcd Learning (3) leader problem in cluster building Clustering