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
Field | Original Value | New Value |
---|---|---|
Assignee | Oleksandr Byelkin [ sanja ] |
Labels | beginner-friendly |
Fix Version/s | 10.5 [ 23123 ] | |
Fix Version/s | 10.6 [ 24028 ] | |
Fix Version/s | 10.11 [ 27614 ] | |
Fix Version/s | 11.1 [ 28549 ] | |
Fix Version/s | 11.2 [ 28603 ] | |
Fix Version/s | 11.4 [ 29301 ] |
Priority | Major [ 3 ] | Critical [ 2 ] |
Assignee | Oleksandr Byelkin [ sanja ] | Sergei Golubchik [ serg ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Status | In Progress [ 3 ] | In Testing [ 10301 ] |
Fix Version/s | 10.5.26 [ 29832 ] | |
Fix Version/s | 10.6.19 [ 29833 ] | |
Fix Version/s | 10.11.9 [ 29834 ] | |
Fix Version/s | 11.1.6 [ 29835 ] | |
Fix Version/s | 11.2.5 [ 29836 ] | |
Fix Version/s | 11.4.3 [ 29837 ] | |
Fix Version/s | 10.5 [ 23123 ] | |
Fix Version/s | 10.6 [ 24028 ] | |
Fix Version/s | 10.11 [ 27614 ] | |
Fix Version/s | 11.1 [ 28549 ] | |
Fix Version/s | 11.2 [ 28603 ] | |
Fix Version/s | 11.4 [ 29301 ] | |
Resolution | Fixed [ 1 ] | |
Status | In Testing [ 10301 ] | Closed [ 6 ] |
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.