[MXS-3459] Malformed packet SQL=LOAD DATA LOCAL INFILE... ERROR 2027 Created: 2021-03-25  Updated: 2021-04-01  Resolved: 2021-04-01

Status: Closed
Project: MariaDB MaxScale
Component/s: readwritesplit
Affects Version/s: 2.5.9
Fix Version/s: 2.5.11

Type: Bug Priority: Major
Reporter: Jozef Kováč Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

UBUNTU 18.04.5 & RHEL 8.3, MariaDB 10.4.18


Attachments: File session_queries.sql    

 Description   

LOAD DATA LOCAL INFILE causing error 2027 Malformed packet for one of ours php application.
Application works without any problem directly connected to MariaDB master server.
Maxscale log has warning entries about "unknown prepared statement" but we don`t use any prepared statements at all.

I tryed disable use_sql_variables_in=master or route all queries directly to master using Hintfilter and Consistent Critical Read Filter but with same result. I also run in same issue with maxscale 2.4.17

Log entries(at same time):
warning: (1) (Splitter-Service) Client requests unknown prepared statement ID '1654551140' that does not map to an internal ID
warning: (1) (Splitter-Service) Using unknown prepared statement with ID 0
error : (1) (master) Write to Backend DCB 10.1.1.121 in state DCB::State::POLLING failed: 104, Connection reset by peer
warning: (1) (Splitter-Service) Client requests unknown prepared statement ID '539915370' that does not map to an internal ID
warning: (1) (Splitter-Service) Using unknown prepared statement with ID 0
error : (1) [readwritesplit] (Splitter-Service) Lost connection to the master server, closing session. Lost connection to master server while connection was idle. Connection has been idle for 0 seconds. Error caused by: #HY000: Lost connection to backend server: connection closed by peer (master). Last close reason: <none>. Last error: Got packets out of order

conf:
[maxscale]
threads=8
syslog=1
maxlog=0
log_notice=1
load_persisted_configs=false
local_address=10.1.1.23
auth_connect_timeout=20s
users_refresh_time=10s
max_auth_errors_until_block=100
admin_gui=0

[master]
type=server
address=10.1.1.121
port=3306
protocol=MariaDBBackend

[slave-1]
type=server
address=10.1.1.14
port=3306
protocol=MariaDBBackend

[Monitor]
type=monitor
module=mariadbmon
servers=master,slave-1
user=xxx
password=xxx
monitor_interval=3s
assume_unique_hostnames=OFF
master_conditions=none
slave_conditions=linked_master
ignore_external_masters=ON

[Splitter-Service]
type=service
router=readwritesplit
servers=master,slave-1
user=xxx
password=xxx
#session_track_trx_state=1
max_slave_replication_lag=5s
max_sescmd_history=500
slave_connections=1
master_accept_reads=true
use_sql_variables_in=master
causal_reads=local
causal_reads_timeout=1s

[ReadWrite-Listener]
type=listener
service=Splitter-Service
protocol=MariaDBClient
socket=/run/maxscale/maxscale.sock



 Comments   
Comment by markus makela [ 2021-03-25 ]

Can you give us some example SQL that reproduces the problem? With the same table and some dummy data I wasn't able to reproduce the problem.

Comment by Jozef Kováč [ 2021-03-26 ]

It happens only for some files, independent of file size or LOAD time, looks similar to https://jira.mariadb.org/browse/MXS-3214 but always for same problematic file.

Comment by markus makela [ 2021-03-26 ]

I think that means some of the data in the LOAD DATA LOCAL INFILE is interpreted as a command when it should be interpreted as data.

Comment by markus makela [ 2021-03-26 ]

I managed to reproduce this by using a binary file with a certain pattern of bytes. Looking at the code it's clear that the query classifier will process the data even during the LOAD DATA LOCAL INFILE which causes the binary data to be treated as a command instead of just data. This is relatively simple to fix as only parts of the code need to be moved around.

From what I can see, there is no current workaround for this apart from loading the data files with a direct connection.

Generated at Thu Feb 08 04:21:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.