Closed cmejiat104 closed 5 months ago
Is your client using JDBC with auto-reconnect enabled?
Is your client using JDBC with auto-reconnect enabled?
Do you mean the client our Users or Services are using to access to Proxysql cluster? if that's the case, I'm not sure, as we have many services from different sources and maybe not all them use the same client config.
I talked to developers and they said:
Hi @cmejiat104 , the important bit in my previous question is actually "with auto-reconnect enabled?" I have seen this problem (I will describe it shortly) with several customers using JDBC and auto-reconnect enabled, and it is possible that other libraries have the same problem. For reference, JDBC auto-reconnect documentation says that the feature is not recommended: https://dev.mysql.com/doc/connector-j/en/connector-j-connp-props-high-availability-and-clustering.html#cj-conn-prop_autoReconnect
Now, what is the issue that crashed ProxySQL?
The client tries to execute a prepared statement that doesn't exist. ProxySQL currently asserts when this happen (this is your backtrace).
When a client tries to execute a prepared statement that doesn't exist?
We have seen many scenarios in which a client is connected to a proxyql instance, it has a prepared statement prepared, then it lose connectivity with proxysql (for whatever reason), it then reconnects (because of autoReconnect
) and tries to execute a prepared statement that doesn't exist anymore: proxysql asserts and crashes.
What happens when you have multiple proxysql instances, and a bugged client with autoReconnect tries to execute a prepared statement that doesn't exist? After crashing the first proxysql, the client will auto-reconnect to the 2nd proxysql instance and try to execute the non-existing prepared statement there too, crashing the 2nd proxysql instance as well. If you have more proxysql instance, this client will crash them all.
I don't know the exact implementation in the libraries you are using, but if you have autoReconnect (or an equivalent named property) please disable it.
For further reference, auto-reconnect is now deprecated also in MySQL C API: https://dev.mysql.com/doc/c-api/8.0/en/c-api-auto-reconnect.html
That said, I acknowledge that this must also be considered a serious bug in proxysql, because a buggy application/driver shouldn't lead to a proxysql crash. We have this in our todo list.
Thank you for your replies.
Unfortunately, modifications in Services' client is not possible at this moment, this is a Prod environment.
We have a UAT environment that was also impacted; although, in this case we only have two instances of ProxySQL, proxysql01 and proxysql02, but Mysql backend has three nodes (mysql01, mysql02 and mysql03) as Prod. In the case of UAT, proxysql01 crashed only once and proxysql02 twice, after that both stayed up and running; of course when this happened, for UAT was out of business hours, so only a few batch processes were running, but for Prod was in the middle of peak hours.
During the network issue, connections to & from proxysql02 and mysql02 dropped (between them were fine), in the case of Prod mysql02 was a Mysql Replica and for UAT mysql02 was the Master. BTW, I don't have any query rule configured, so all the transactions go always to the Mysql Master.
Might this another issue also related to my Proxysql crashes?
It is the same issue, yes
Ok thanks!, but the fix mentioned in the comments is not in place yet, right?
The fix mentioned in the comments is not in place yet because it is not complete.
This issue is closed by #4481
Thank you!
Hello,
I have a Proxysql cluster with 3 nodes in front of a Percona Mysql server 5.7 configured with one MASTER and two REPLICAS (asynchronous replication).
Servers are running inside a private cloud; the environment is compound by three zones (like regions). In the Zone 01, we have two servers running proxysql01 and mysql01, same configuration in Zone 02 and Zone 03.
Recently there was a modification in one of our firewalls that isolated Zone 02, so proxysql01 and proxysql03 weren't able to talk to proxysql02 node and none of them were able to talk to mysql02 replica.
The 3 ProxySQL nodes started crashing and generating cores and even when Zone 02 access was fixed, instances were still crashing till
/
filesystem was full.These are the messages found in Proxysql logs:
proxysql01:
Proxysql version:
Mysql version:
OS version:
Cores content:
When we noticed the problem, our workaround was stopping all the three proxysql services, cleaning up
/
filesystem on each server and only starting Proxysql service in node 01, once this one was up and running, I did the same with the other two nodes.We don't understand why the two healthy Proxysql nodes were not able to continue running, but crashing in an endless loop.
I hope you can give me any advice.
Thank you in advanced.
Regards,