Open pali opened 5 years ago
Sometimes killing proxysql process and starting it again helps to pass test script.
Thank you for the report.
This issue seems caused by multiplexing not being disabled in CREATE TEMPORARY TABLE
.
Is surely needs more investigation.
And important is that this problem happens only when using MySQL binary protocol (prepared statements). When using MySQL text protocol I was not able to reproduce this problem.
What else for investigation is needed? I have there reproducer script together with its output.
I haven't reproduce it yet, but I think the script you wrote makes it very easy to reproduce it. Thank you!
I am pretty confident the issue is caused by multiplexing not being disabled in CREATE TEMPORARY TABLE
because the need of disabling multiplexing is not stored in prepared statements metadata .
This behavior largely differs from text protocol, where there is no metadata cache and each single query is sent to Query Processor for evaluation.
Hi! Is there any progress on this issue?
Any updates?
from https://proxysql.com/documentation/multiplexing/:
Note: disabling multiplexing doesn’t disable routing, so it might happen that after a CREATE TEMPORARY TABLE is executed, a SELECT query on the same table returns a 'schemaname.temporary_tablename' doesn't exist error message. The reason for this is that while multiplexing is disabled, routing isn’t – and if the two statements are sent to two different hostgroups, the error message will appear. To prevent this, it is advised to use query routing. See [MySQL query rules](https://proxysql.com/documentation/main-runtime/#mysql_query_rules).
Based on my reading of above, if I know these queries hit the same hostgroup, would disabling multiplexing mitigate this issue?
When client uses MySQL binary protocol (that one which supports prepared statements) and communicating with ProxySQL, then ProxySQL incorrectly process commands and cause random errors, including data lost, random execution of commands, random errors, and also leaking session private settings to different sessions. Result is that
CREATE TABLE
orDROP TABLE
statements are sometimes not executed on backend server or sometimes sequent INSERT/SELECT commands fails as table does not exist at all. All this happen when using concurrent multiprocess access to database via ProxySQL and is random.For demonstration, below is simple perl script. When running multiple times, it fails with different errors, like
Table 'test.t1' doesn't exist
orTable 't1' already exists
or int1
table is stored number10
multiple times or int1
table is number10
missing at all.Above just makes ProxySQL unusable with server side prepared statement / MySQL binary protocol as ProxySQL just damage data or incorrectly propagates them to backend server database. When server side prepared statements are not used, then everything is OK. But not using prepared statement is a security risk -- SQL injections. Please note that command line
mysql
tool does not support prepared statement / MySQL binary protocol, thereforemysql
tool cannot be used for checking for this problem. And some other scripting language is needed.Here is that perl script for testing:
Run it in parallel and multiple times. Replace
root
androot_password
by login credentials.mysql_server_prepare
cause that MySQL binary protocol and server side prepared statements (for placeholders) is used.Below is output from that script called multiple times. You can see that it fails randomly on random lines with bizarre errors about non-existent table or that table exists after dropping it.