Proxysql 2.5.5 cluster crashing after losing access to a Mysql 5.7 replica about proxysql HOT 11 CLOSED

The fix mentioned in the comments is not in place yet because it is not complete.

from proxysql.

Is your client using JDBC with auto-reconnect enabled?

from proxysql.

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.

from proxysql.

I talked to developers and they said:

• for C++ services, they use "Maria DB C Connector 3.3.1"
• for NodeJs services, they use this library https://www.npmjs.com/package/mysql/v/2.18.1

from proxysql.

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.

from proxysql.

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.

from proxysql.

Might this another issue also related to my Proxysql crashes?

#3371

from proxysql.

It is the same issue, yes

from proxysql.

Ok thanks!, but the fix mentioned in the comments is not in place yet, right?

from proxysql.

This issue is closed by #4481

from proxysql.

Thank you!

from proxysql.