Install matching mysql/mysqldump/mariadb-dump client inside ddev-webserver based on mysql or mariadb database type

[rfay]

In general, the mysql client shipped with the ddev-webserver works fine with all mariadb and mysql back-end databases.

However, there are a few cases where their behavior is slightly different.

And the fact that the mysql client reports a different version is often confusing to people.

For example, with database mysql:8.0 we see these outputs:

rfay@rfay-mbp-2021:~/workspace/d10$ ddev exec mysql --version
mysql  Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (aarch64) using  EditLine wrapper

rfay@rfay-mbp-2021:~/workspace/d10$ ddev exec -s db mysql --version
mysql  Ver 8.0.33-0ubuntu0.20.04.2 for Linux on aarch64 ((Ubuntu))

The web container has the mariadb version, and the db container has the mysql:8.0 version.

On Craft CMS and perhaps some other places, people have the habit of using the built-in tools; Craft actually calls out to the mysql client (on ddev-webserver) rather than connecting directly to the database server, so this can cause confusion there.

• https://discord.com/channels/664580571770388500/1227934688505630721/1227934688505630721
• https://discord.com/channels/664580571770388500/1189581731301429318
• https://discord.com/channels/664580571770388500/1160230833601392791/1160258585633247302

Proposal

Add a layer to the ddev-webserver adding a matching mysql client to the ddev-webserver, especially where the database type is mysql:8.0, which is the most likely place for concern.

It also might be possible to implement this as an add-on for the few people it matters to. It's tricky getting the proper match between the OS-provided mysql client and the ddev-webserver, and it could introduce instabilities.

[stasadev]

Answering to #6139 (comment) in the relevant issue:

Is there something like that where we can get the mysql version of the client also?

There is mysql-apt-config https://dev.mysql.com/doc/refman/8.4/en/linux-installation-apt-repo.html

The current latest version is 0.8.30 https://dev.mysql.com/get/mysql-apt-config_0.8.30-1_all.deb

How to install mysql-server in non-interactive way https://stackoverflow.com/a/37267411/8097891

The SO example needs to be modified to change the server to client, but I think it's an achievable goal.

[rfay]

I'm not sure there's a client package, but if there is this can be great!

[rfay]

Now that MariaDB has released mariadb-dump/mysqldump versions that are completely incompatible with "traditional" versions, we're going to have to prioritize this.

From: https://mariadb.com/kb/en/mariadb-dump/

Note: From MariaDB 10.5.25, MariaDB 10.6.18, MariaDB 10.11.8, MariaDB 11.0.6, MariaDB 11.1.5, MariaDB 11.2.4 and MariaDB 11.4.2 mariadb-dump generates a command at the beginning of the dump to enable sandbox mode. This command cannot be interpreted by earlier versions of the MariaDB command line client or by MySQL's command line client, and the client will generate an error if used against the versions that do not support it. This does not affect other methods of importing the data.

Basically, all the latest supported patch versions of mysqldump from mariadb are completely incompatible (without workarounds) with the previous patch version. So mariadb-dump/mysqldump 10.6.18's version is incompatible with 10.6.17. What's up with them!!!

• MariaDB 10.6.18 seems to generate invalid SQL dumps
• mariadb-dump trusts the server and does not validate the data

Unfortunately, there isn't much we can do about it. This change came as a fix for CVE-2024-21096, and security fixes can sometimes break backward compatibility.

In this particular case, though, there are plenty of workarounds:

• you can use the new mariadb client to restore the backup on the old MariaDB/MySQL server
• you can use old mariadb-dump to make a backup of the new MariaDB server
• you can use mariadb-dump|tail +2 to remove the problematic line when making a backup
• you can use tail +2|mariadb to remove the problematic line when applying a backup

[manutepowa]

Indeed mariadb has added sandbox mode, and database backups fail.
https://jira.mariadb.org/browse/MDEV-34183

[rfay]

MariaDB Blog about the change to dump file format: https://mariadb.org/mariadb-dump-file-compatibility-change/

[cristiroma]

FYIW - We are mitigating with the following commands on the web container:

docker exec -ti ddev-PROJECT-web bash
sudo apt remove mariadb-client -y
sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.11"
sudo apt install mariadb-client -y

[rfay]

Thanks @cristiroma - It would be a lot better as a .ddev/web-build/Dockerfile.mariaclient or something, you wouldn't have to do it all the time.

[v11ncent]

I was able to import a file dumped with the new mariadb-dump by deleting the line at the top of the dump that says /*!999999\- enable the sandbox mode */ in my MariaDB dump file.

[rfay]

The affected DDEV database images have been pushed with updated mariadb tools, please see

• ddev import-db fails with "Error: Unknown command '\-'" because of new directive in mariadb-dump output #6249 (comment) if you're dealing with the broken mysqldump issues.

[Defcon0]

FYIW - We are mitigating with the following commands on the web container:

docker exec -ti ddev-PROJECT-web bash
sudo apt remove mariadb-client -y
sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.11"
sudo apt install mariadb-client -y

Doesn't work anymore:

$ sudo apt remove mariadb-client -y
sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.11"
sudo apt install mariadb-client -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libconfig-inifiles-perl libdbd-mariadb-perl libdbi-perl libmariadb3 libterm-readkey-perl mariadb-client-core mariadb-common mysql-common
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  mariadb-client
0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.
After this operation, 64,4 MB disk space will be freed.
(Reading database ... 59191 files and directories currently installed.)
Removing mariadb-client (1:10.11.6-0+deb12u1) ...
bash: line 1: error: command not found
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  mariadb-client
0 upgraded, 1 newly installed, 0 to remove and 9 not upgraded.
Need to get 2.931 kB of archives.
After this operation, 64,4 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bookworm/main amd64 mariadb-client amd64 1:10.11.6-0+deb12u1 [2.931 kB]
Fetched 2.931 kB in 0s (7.489 kB/s)      
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package mariadb-client.
(Reading database ... 59089 files and directories currently installed.)
Preparing to unpack .../mariadb-client_1%3a10.11.6-0+deb12u1_amd64.deb ...
Unpacking mariadb-client (1:10.11.6-0+deb12u1) ...
Setting up mariadb-client (1:10.11.6-0+deb12u1) ...

[stasadev]

@Defcon0,

It's working, https://r.mariadb.com/downloads/mariadb_repo_setup was down, but it's fine now.

[rfay]

The mariadb:10.11 approach described above (from https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/) does work currently.

However, 10.6 does not work, on either amd64 or arm64 with Debian Bookworm:

$ sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.6"
# [info] Checking for script prerequisites.
# [error] MariaDB Server version 10.6 is not working.
#         Please verify that the version is correct.
#         Not all releases of MariaDB are available on all distributions.
#
#         The latest MariaDB Server versions are:
#             10.4.34 10.5.25 10.6.18 10.11.8 11.0.6 11.1.5 11.2.4 11.4.2 11.5.1
#
#         More information on MariaDB releases is available at:
#             https://mariadb.com/kb/en/release-notes/

And of course, 10.6 is the exact example they provide in their docs.

Opened https://jira.mariadb.org/browse/MDEV-34339

[rfay]

However, I'll bet that the mariadb 10.11 client will work for most of the mariadb situations. That's a pretty simple approach.

[rfay]

mysql has never provided arm64 packages for Debian/Ubuntu, and they still don't. Info about their apt repo is at https://dev.mysql.com/doc/mysql-apt-repo-quick-guide/en/

Ubuntu does package mysql server for arm, it's conceivable that we can steal the client and its dependencies from a related Ubuntu version. This is how we do mysql server for DDEV, see https://ddev.readthedocs.io/en/stable/developers/release-management/#maintaining-ddev-dbserver-mysql-57-and-80-arm64-images

[rfay]

It looks like if we want to do the mysql client, we'll have to build from source, https://dev.mysql.com/doc/mysql-installation-excerpt/8.0/en/source-installation.html, as we do for xtrabackup.

[rfay]

One thing we could do for mariadb is to replace mysqldump and mysql with wrappers that strip /*!999999\- enable the sandbox mode */. That sure seems intrusive to me.

[rfay]

I think

• fix: Use mariadb repositories for mariadb-client, for #6083 #6290 (comment) may solve this problem for those who have application-defined backup/restore packages that happen in the web container. I'd sure appreciate it if you'd test.

[rfay]

Mostly what we have left to do on this one is to try for matching psql clients.

[timnolte]

So this issue is now majorly burning us on new projects that use AWS Aurora DBs where we need to set the DDev version to MySQL. We're running into major issues and due to all of the requirements we have we need to be running MySQL 5.6. I see that just today a commit was made to address MySQL 5.7 & 8.0, I don't see any fixes for 5.6 though. This is causing issues for WP-CLI to do a db export.

[rfay]

@timnolte I assumed that MySQL 5.6 was so far out of support (even 5.7 is EOL) that nobody would be using it.

If you use ddev export-db things should be fine, as everywhere on the db container we're removing the offending parts of the dump. I assume it's critical to you to use wp-cli?

Could you please give the exact scenario and result that you get?

[rfay]

As a last-ditch attempt to provide solutions for unusual situations, we're putting an older mysql/mysqldump/mariadb/mysqldb-dump into the ddev-webserver in /usr/local/mariadb-old/bin. This will be usable by adding /usr/local/mariadb-old/bin into the PATH inside the container before /usr/bin. Until this last month, the mariadb client and mysqldump have been compatible with MySQL and MariaDB for 20 years. So making the old version available there is another shot at this. This is currently testing in today's

• test: Fix TestAcquiaPush and TestLagoonPush, add mariadb-old clients, fixes #6295 #6304

[timnolte]

We had some major compatibility issues between MariaDB, MySQL, and Aurora DB(AWS) along with a WordPress plugin from Automattic that we use for distributed database connectivity. We need to be on a MySQL version in DDev in order to be able import backups from the Aurora DB but I think because the web container wasn't using a compatible client it was causing major local WordPress site setup failures. The only way we could get a site install working locally and an Aurora DB database backup to restore was to use MySQL version 5.6. However, we just discovered today that now the WP-CLI commands fail and we leverage that a lot for our setup.

I would be inclined to try and see if MySQL 8.0 will work the way we need it to if that version of the client is actually installed in the web container.

[rfay]

I would appreciate it if you'd try the current HEAD, preferably with MySQL 5.7 or 8.0. Also if you can come up with the actual specific scenario it will help.

Previously, the DDEV web container always had a MariaDB client in it. Now if 5.7 or 8.0 it will have the related mysql client in it.

[timnolte]

OK, will give 5.7 or 8.0 a try. I don't recall, how do I go about installing the HEAD. I've been using the install_ddev.sh script for awhile as I install to my home directory. I was looking through the script and I thought that it was only pulling from the releases.

[rfay]

I gave you the link to the docs in my request above. #6083 (comment)

[timnolte]

Oops, doing this on my phone since it's out of my working hours. Will circle back around tomorrow.