-
Notifications
You must be signed in to change notification settings - Fork 976
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
fast_forward=1 breaks failover handling #2590
Comments
Forgot to add: After pt-heartbeat is cycled the OFFLINE_HARD server is removed from the hostgroup. Also pt-heartbeat is just a simple example, our application behaves the same way. |
This behavior is expected when using |
To be clear, when |
Yes, on 1.4 it switches the connection to the new master once it becomes available. I reproduced that yesterday to figure out why we started seeing read-only errors after the switch to 2.x last weekend. Ok, then we have to figure out why we are getting that one error once we turn fast_forward off. The reason we turned it on was we were getting this:
Even though there was only one result row in the database. Development insists that this is a proxysql error because it only happens with the proxy but i have a different opinion... Thank you for the quick comment and let me tell you that you are doing awesome work on this :) |
Not 1.4 or 2.0 can switch existing connections in Although, what is possible is that you were experiencing something else in 1.4 , let me make some hypothesis... Something relevant in the error log is this line:
To highlight the important part:
There is also the probability that "Used connections will be dropped when trying to use them" is handled differently in 1.4 and 2.0 . ==== About:
I am not sure what was causing this without much context, but I can make an educated guess and make the hypothesis that your application was relying on |
Thanks for taking a look at this. One thing against your hypothesis is that all this happens with only one process accessing proxysql - that is the pt-heartbeat process. Also that i was able to reproduce this with versions 2.0.3 up to 2.0.10. About the hibernate thing - we started using proxysql 2 with 2.0.7 so i only after the behavior was changed and we still see the same thing. It´s pretty difficult to analyze this. I´ll try messing around with the query logging later to check if i can see something. These are my results of reproducing with a 1.4.13 version. Complete removal and resetup, so no old proxysql data files were used. Everything else was the same. pt-heartbeat log
after that nothing and pt-heartbeat is updating the heartbeat table on the new server. Proxysql log
If you require anything else i´m very happy to help. |
Thank you for the output. @Val214 : can you please reproduce it? No need for pt-heartbeat, a simple mysql client connection would work. |
Running pt-heartbeat with debug log indicates that the connection is reset on the 1.4 version. Debug Output of 1.4
Debug output of 2.0.7
|
Thank you again for the output!
|
I don´t know if you want to follow this up somehow or if we should close it. As i understood it´s actually "working as intended". |
Versions 2.0.11 and 1.4.16 behave differently when master switch with fast_forward=1. In case of 1.4.16 mysql client disconnects from proxysql and try to re-connect. In case of proxysql v2.0.11 client does not try to reconnect. Please have a look over detailed info here https://gist.github.com/val214/84ba9cda6ef83e6e39ae4e3fe1979727 |
Closing this as we are soon releasing 2.0.11 . |
Issue: When using fast_forward=1 and switching the backend-master (setting the old to read only and making a new one writeable) existing connections still talk to the old master and hit a read-only error.
RHEL7.6 / Proxysql 2.x (tested 2.0.3 up to 2.0.10)
Reproduce:
-> Orchestrator sets old master to read_only, makes new master writeable
Expected behavior (this works in 1.x): application talks to new master.
Output & Logs:
Everything running fine. Now we perform a graceful takeover with orchestrator.
pt-heartbeat output
and this continues endlessly.
proxysql shows
proxysql logfile:
The text was updated successfully, but these errors were encountered: