-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
etcd client v3 can switch addr in endpoints like v2? #7941
Comments
What sort of request failures? |
@gyuho I had passed three endpoints when I new a client. Do I need call |
@heyitsanthony I passed three endpoints when I new a client. Shutdown one of etcd server network, I found etcd client v3 always request fail. |
@YuleiXiao what version of etcd server / client? Steps to reproduce? What errors? clientv3 has test cases for this; it should reconnect to another node if one is down... |
I test when I new client with three endpoints and disable auto-sync, the probability of occurrence is greater. |
@YuleiXiao could you try https://github.com/coreos/etcd/releases/tag/v3.2.0-rc.1 to see if that solves your issue. There are some bug fixes related to |
@fanminshi I had try 3.2, it is the same problem. |
I am facing similar issues where a client reports
|
@adityadani |
@adityadani could you easily reproduce the issue you were describing? |
I am using clientv3 at v3.1.8. |
Hi, @fanminshi! If it matters, I'm talking about Watch() automatic failover. |
@mwf 15 mins seems too long. I expect it to automatically swtich as soon as connection issue is detected. What version of etcd are you using? are you able to reproduce this issue easily? also could you test your code against the latest master branch. I guess #8545 should fix the endpoint issue you have. |
Ohh, finally! I hope #8545 will fix all the issues we have. We are using 3.1.5 server (it should not matter here) and 3.2.5 client. 15 minutes is some "standard" time for all issues people have with Watch freeze and network partitioning with current stable releases. Hope it changes in master. It's easily reproducable. Thanks! If 15 minutes failover still exists in master I will let you know. |
Closing this in favor of #8022.
This will be shipped in our upcoming v3.3 release. |
@YuleiXiao Please give etcd/client master a try. let us know if the problem is fixed. thank you. |
@xiang90 OK, I will test it and give test result later. Thanks very much. |
@xiang90 It looks like same problem. watch on a key. Client connect to 192.168.128.37 first.
shutdown the eth on 192.168.128.37
put a value, put fail first. Client watch still no any change to other server.
|
it seems that the endpoint is malformed. |
@xiang90 I think format is OK because I put it success before eth5 down |
@YuleiXiao Try without brackets in
|
@gyuho I remove brackets, it did not report malformed. But client watch still not switch.
|
@gyuho can you take a look? |
@YuleiXiao Oh. Probably that is the cause, can you also send a PR to fix that if you can confirm it is the root cause? |
@xiang90 sure |
@YuleiXiao awesome. thank you. |
Does etcdv3 go client have this option? |
@gyuho Is this shipped in v3.3 or v3.4? |
etcd v2 will switch address in endpoints when request fail. But I use etcd v3, and it looks like not switch when fail.
Is there any parameter need set to open it?
The text was updated successfully, but these errors were encountered: