Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
11.4.2
-
Client: Arch Linux / mariadb-clients-11.4.2-1
Server: Percona Xtradb cluster operator v1.14.0
mysql Ver 8.0.27-18.1 for Linux on x86_64 (Percona XtraDB Cluster (GPL), Release rel18, Revision ac35177, WSREP version 26.4.3)
Description
Hi!
Hopefully we can report bugs regarding mariadb-dump -> Percona/MySQL?
Simply running mariadb-dump -h <hostname> -u <username> -p<password> db causes the following error:
mariadb-dump: Couldn't execute '/*!100100 SET @@MAX_STATEMENT_TIME=0.000000 */': You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '0 SET @@MAX_STATEMENT_TIME=0.000000 */' at line 1 (1064)
Running the same command using a bookworm container works:
user@component-755c5bbd69-t5l82$ mariadb-dump --version
mariadb-dump Ver 10.19 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64)
user@component-755c5bbd69-t5l82$ mariadb-dump -h $DB_HOSTNAME -u $DB_USERNAME -p$DB_PASSWORD $DB_NAME
– MariaDB dump 10.19 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64)
–
-- Host: mysql1-haproxy.<namespace>.svc.cluster.local Database: [redacted]
– ------------------------------------------------------
– Server version 8.0.27-18.1
[snip]
So something (presumably MDEV-18702?) broke compatibility with the Percona/MySQL server setup.
I haven't been able to set a workaround, as it does not seem there is any way to disable setting MAX_STATEMENT_TIME. I can use --max_statement_time=0 or --max_statement_time= to set the value to 0 but that doesn't remove the statement. Only solution for my use case seems to run an older version of mariadb-dump, or to use a MySQL client (which is probably better against a MySQL server of course, but that is inconvenient as I simply wish to use my distribution's MariaDB client).
$ mariadb-dump --print-defaults
mariadb-dump would have been started with the following arguments:
Attachments
Activity
We can still easily improve the compatibility by using !M comments
Having the same issue against an AWS Aurora database. Client reports the following error
Couldn't execute '/*!100100 SET @@MAX_STATEMENT_TIME=0.000000 */': You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '0 SET @@MAX_STATEMENT_TIME=0.000000 */' at line 1 (1064)
Also on Arch Linux / mariadb-clients-11.4.2-1
I'd like to report that on 11.4.3 the related line to set `WAIT_TIMEOUT` is still breaking mariadb-dump connections with MySQL server 8.0.39:
mariadb-dump: Couldn't execute '/*!100100 SET WAIT_TIMEOUT=DEFAULT */': You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '0 SET WAIT_TIMEOUT=DEFAULT */' at line 1 (1064)
|
Versions:
mysqldump from 11.4.3-MariaDB, client 10.19 for debian-linux-gnu (x86_64)
mysql Ver 8.0.39-0ubuntu0.22.04.1 for Linux on x86_64 ((Ubuntu))
I'm not entirely sure, but I think this was an oversight when merging changes from the 11.2 branch into 11.4.
While present on 11.2, the following change does not seem to be present on 11.4:
https://github.com/MariaDB/server/commit/d60f5c11ea9008fa57444327526e3d2c8633ba06#diff-2af757996671100e35b2650825a86d9a7f3d2b3bc538e9267c4195ca2e0b19caR6958
Thanks. It looks like a merge mistake indeed. Fixed now, will be in the next release.
For the record, this was reported in Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084786
This looks like a bug in Percona/MySQL server. The conditional comment
/*!100100 SET @@MAX_STATEMENT_TIME=0.000000 */
means there's a version 100100 (= 10-01-00, that is 10.1.0) and the content SET @@MAX_STATEMENT_TIME=0.000000 should only be executed if the server version is not below 10.1.0.
But apparently, Percona/MySQL server reads it as the version 10010 (= 1.0.10) and the content is 0 SET @@MAX_STATEMENT_TIME=0.000000. 8.0.27 is above 1.0.10, so it tries to execute it and gives a syntax error at the first 0.