[MDEV-25892] cannot INSTALL SONAME 'ha_sphinx'; Created: 2021-06-10  Updated: 2021-06-16  Resolved: 2021-06-15

Status: Closed
Project: MariaDB Server
Component/s: Plugins
Affects Version/s: 10.4.18
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Karl Klepper Assignee: Daniel Black
Resolution: Not a Bug Votes: 0
Labels: alpine, docker, sphinx
Environment:

docker alpine



 Description   

I have a 10.1.26 docker alpine container based on a previous version of Johan Bergström working with sphinx (on docker hub kklepper/mariadb33).

In order to upgrade, I adopted the new version of Johan (kklepper/mariadb33-10.4.18) in which I cannot activate the sphinx plugin:

M:2521920 [(none)]>INSTALL SONAME 'ha_sphinx';
ERROR 1126 (HY000): Can't open shared library '/usr/lib/mariadb/plugin/ha_sphinx.so' (errno: 13, Error relocating /usr/lib/mariadb/plugin/ha_sphinx.so: _ZNK30Type_handler_hybrid_field_type26get_handler_by_result_typeE11Item_r)

Unfortunately, this plugin is crucial for my application, so I have to fix this.

The error message is enigmatic for me, however, and I have no idea of how to debug this.

I added ha_sphinx.so to /usr/lib/mariadb/plugin/ manually. The original file is indeed present at the given path and file privileges do not matter.

The former image features 36 plugins. I had to manually add ha_sphinx.so in previous versions, so I guess the appropriate alpine package had been augmented.

What can I do to resolve this problem? Is it a problem of MariaDB or of the alpine package involved?



 Comments   
Comment by Karl Klepper [ 2021-06-11 ]

I told Johan Bergstroem about this and he wrote: "This is probably not a bug, just a consequence of shaving off bytes."

I tested this hypothesis – indeed he shaves off all plugins, which would be ok as ha_sphinx.so is not among them anyway. If I prevent deletion of what he deems to be dispensable I still get this same error.

Comment by Daniel Black [ 2021-06-11 ]

If you use the official docker library it include a few extra bytes including a working ha_sphinx.so that you require.

$ podman run -d --name mdb10.4 -e MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1  docker.io/library/mariadb:10.4
fcd33c10dccccdfe7c595a2d7d6684666b4bde6a1fa2cf971f476182900779a6
 
$ podman exec -ti mdb10.4 mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.4.19-MariaDB-1:10.4.19+maria~focal mariadb.org binary distribution
 
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
MariaDB [(none)]>   INSTALL SONAME 'ha_sphinx';
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    8
Current database: *** NONE ***
 
Query OK, 0 rows affected (0.003 sec)
 
MariaDB [(none)]> Bye
 
$ podman exec -ti mdb10.4 mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.4.19-MariaDB-1:10.4.19+maria~focal mariadb.org binary distribution
 
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
MariaDB [(none)]>   INSTALL SONAME 'ha_sphinx';
Query OK, 0 rows affected (0.001 sec)

I did need to install it twice, The first error cases 2021-06-11 13:39:54 8 [Warning] Plugin 'SPHINX' is of maturity level gamma while the server is stable
in the server log, however on the second running of INSTALL PLUGIN it just works. I'll look at why that is probably next week but this should be enough to get you working.

The relocation error is due to a mixing of the sphinxse and a different mariadb version.

Comment by Karl Klepper [ 2021-06-11 ]

Thank you. I used INSTALL SONAME 'ha_sphinx'; twice with no difference.

As far as I remember I had a bad time finding ha_sphinx.so and it is very probably that this file is outdated. Where can I find a current version?

Googling brought me https://www.rpmfind.net/linux/rpm2html/search.php?query=ha_sphinx.so()(64bit) with 10.0.x versions only (probably not only the .so file). Is that the right one?

Comment by Daniel Black [ 2021-06-11 ]

Set plugin_maturity=gamma in your configuration. Google copy/paste/no analysis/move file X will just end in tears like where you started. Look at log files. Read and understand.

Comment by Karl Klepper [ 2021-06-11 ]

Thank you very much.

/ # ls -latr /usr/lib/mariadb/plugin/
total 96
-rwxr-xr-x 1 root root 96320 Oct 3 2019 ha_sphinx.so
drwxr-xr-x 1 root root 20 Jun 9 14:46 ..
drwx------ 2 root root 6 Jun 9 14:46 auth_pam_tool_dir
drwxr-xr-x 1 root root 26 Jun 11 18:29 .
/ # cat /etc/mysql/my.cnf | grep "plug"
plugin_maturity=gamma

mysql.err

2021-06-11 18:30:21 0 [ERROR] mysqld: Can't open shared library '/usr/lib/mariadb/plugin/ha_sphinx.so' (errno: 0, Error relocating /usr/lib/mariadb/plugin/ha_sphinx.so: _ZNK30Type_handler_hybrid_field_type26get_handler_by_result_typeE11Item_r)
2021-06-11 18:30:21 0 [ERROR] mysqld: Can't open shared library '/usr/lib/mariadb/plugin/metadata_lock_info.so' (errno: 2, Error loading shared library /usr/lib/mariadb/plugin/metadata_lock_info.so: No such file or directory)

Hope that helps. What more am I to read and understand?

I installed the latest mariadb on CentOS 8

  1. rpm -qi MariaDB-server
    Name : MariaDB-server
    Version : 10.5.10
    Release : 1.el8
    Architecture: x86_64
    Install Date: Fri 11 Jun 2021 04:48:20 PM CEST
    Group : Applications/Databases
    Size : 133287650
    License : GPLv2
    Signature : DSA/SHA1, Fri 07 May 2021 03:45:53 AM CEST, Key ID cbcb082a1bb943db
    Source RPM : MariaDB-server-10.5.10-1.el8.src.rpm
    Build Date : Thu 06 May 2021 10:30:29 AM CEST
    Build Host : rhel8-amd64
    Relocations : (not relocatable)
    Vendor : MariaDB Foundation
    URL : http://mariadb.org
    Summary : MariaDB: a very fast and robust SQL database server
    Description :
    MariaDB: a very fast and robust SQL database server

It is GPL v2 licensed, which means you can use the it free of charge under the
conditions of the GNU General Public License Version 2 (http://www.gnu.org/licenses/).

MariaDB documentation can be found at https://mariadb.com/kb
MariaDB bug reports should be submitted through https://jira.mariadb.org

  1. systemctl status mariadb
    ● mariadb.service - MariaDB 10.5.10 database server
    Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/mariadb.service.d
    └─migrated-from-my.cnf-settings.conf
    Active: active (running) since Fri 2021-06-11 18:56:46 CEST; 2s ago

SHOW plugins delivers 68 entries, no sphinx

Now what?

Comment by Karl Klepper [ 2021-06-11 ]

Surprise:
MariaDB [(none)]> INSTALL SONAME 'ha_sphinx';
Query OK, 0 rows affected (0.012 sec)

What do I learn from this with respect to docker?

Comment by Karl Klepper [ 2021-06-11 ]

show plugins;
...

SPHINX ACTIVE STORAGE ENGINE ha_sphinx.so GPL

----------------------------------------------------------------------------
69 rows in set (0.001 sec)

Comment by Karl Klepper [ 2021-06-11 ]

Interestingly, there is no plugin subdirectory of /usr/lib/mariadb. Instead, ha_sphinx.so is placed in this directory now and it is the same I already own.

From this I conclude this file is produced on the fly.

If so, why the error message to being with?

Comment by Karl Klepper [ 2021-06-11 ]

I'm sorry, I have to correct myself. Looking again, everything is as expected.

MariaDB [(none)]> SHOW VARIABLES LIKE '%plu%';
-----------------------------------------+

Variable_name Value

-----------------------------------------+

plugin_dir /usr/lib64/mysql/plugin/
plugin_maturity gamma

-----------------------------------------+
2 rows in set (0.007 sec)

I don't think I hallucinated back 3 hours ago and don't have an explanation for this.

Comment by Karl Klepper [ 2021-06-11 ]

Well, look twice: it is lib64, not lib and mysql, not mariadb, which is somehow not quite consistent:

  1. ls -latr /usr/lib/mariadb/plugin
    ls: cannot access '/usr/lib/mariadb/plugin': No such file or directory
  1. ls -latr /usr/lib64/mariadb/plugin
    ls: cannot access '/usr/lib64/mariadb/plugin': No such file or directory
  1. ls -latr /usr/lib/mysql/plugin
    ls: cannot access '/usr/lib/mysql/plugin': No such file or directory
  1. ls -latr /usr/lib64/mysql/plugin/ha_sphinx.so
    -rwxr-xr-x 1 root root 149304 May 6 10:29 ha_sphinx.so
  1. ls -latr /usr/lib/mariadb/ha_sphinx.so
    -rwxr-xr-x 1 root root 96320 Jun 11 18:13 /usr/lib/mariadb/ha_sphinx.so
Comment by Daniel Black [ 2021-06-11 ]

Use docker logs container_name to view the logs from any container. RPMs package things slightly different to the Ubuntu focal that is the basis for the Docker Library mariadb contains. I'm not going to advise on anything apart from the Docker Library mariadb container that I largely got working in 3 minutes.

For a bug report this is quite unfocused as to what you are using from where. Collect your thoughts and focus a bit more and write clearly. If this is still a mess next week when I look at it gain it will be closed.

Comment by Karl Klepper [ 2021-06-12 ]

Thorough investigatio, as best I can:

10.5.10 on host:

  1. mysqld --print-defaults
    mysqld would have been started with the following arguments:

As we have no arguments, the following is built in:

MariaDB [(none)]> SHOW VARIABLES LIKE '%plu%';
-----------------------------------------+

Variable_name Value

-----------------------------------------+

plugin_dir /usr/lib64/mysql/plugin/
plugin_maturity gamma

-----------------------------------------+
2 rows in set (0.007 sec)

I don't think I hallucinated back 3 hours ago and don't have an explanation for this.

Well, look twice: it is lib64, not lib and mysql, not mariadb, which is somehow not quite consistent:

  1. ls -latr /usr/lib/mariadb/plugin
    ls: cannot access '/usr/lib/mariadb/plugin': No such file or directory
  1. ls -latr /usr/lib64/mariadb/plugin
    ls: cannot access '/usr/lib64/mariadb/plugin': No such file or directory
  1. ls -latr /usr/lib/mysql/plugin
    ls: cannot access '/usr/lib/mysql/plugin': No such file or directory
  1. ls -latr /usr/lib64/mysql/plugin/ha_sphinx.so
    -rwxr-xr-x 1 root root 149304 May 6 10:29 ha_sphinx.so
  1. ls -latr /usr/lib/mariadb/ha_sphinx.so
    -rwxr-xr-x 1 root root 96320 Jun 11 18:13 /usr/lib/mariadb/ha_sphinx.so

So this was an insight from 10.5.10 on host:

There is no /usr/lib/mariadb/plugin, but /usr/lib64/mysql/plugin/ has all the files, and additionally /usr/lib/mariadb/ has the installed plugin.

Maybe it is just a hickup in renaming things. Let's try and define the plugin_dir.

In the Dockerfiles, I made sure I created the directory /usr/lib64/mariadb/plugin and copied ha_sphinx.so to this folder, then changed my.cnf and added plugin_dir=/usr/lib64/mysql/plugin/.

This did not help for 10.4.18, though:

M:2521920 [(none)]>select version();
---------------------

version()

---------------------

10.4.18-MariaDB-log

---------------------
1 row in set (0.000 sec)

M:2521920 [(none)]>SHOW VARIABLES LIKE 'plu%';
-----------------------------------------+

Variable_name Value

-----------------------------------------+

plugin_dir /usr/lib64/mysql/plugin/
plugin_maturity gamma

-----------------------------------------+
2 rows in set (0.001 sec)

M:2521920 [(none)]>INSTALL SONAME 'ha_sphinx';
ERROR 1126 (HY000): Can't open shared library '/usr/lib64/mysql/plugin/ha_sphinx.so' (errno: 13, Error relocating /usr/lib64/mysql/plugin/ha_sphinx.so: _ZNK30Type_handler_hybrid_field_type26get_handler_by_result_typeE11Item_r)

This is the same error I had before and I get it with 10.5.9 as well. If I omit the plugin_dir directive, plugin_dir = /usr/lib/mariadb/plugin/, but it makes no difference.

So for me this is proof it is not a docker or container definition problem.

I will test with 10.4 if I can. Well, I cannot. I removed 10.5, installed 10.4, started, but got an error.

  1. systemctl status mariadb
    ? mariadb.service - MariaDB 10.4.19 database server
    Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/mariadb.service.d
    +-migrated-from-my.cnf-settings.conf
    Active: failed (Result: exit-code) since Sat 2021-06-12 01:59:44 CEST; 5min ago
    Docs: man:mysqld(8)
    https://mariadb.com/kb/en/library/systemd/
    Process: 1736166 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
    Process: 1736156 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=cd /usr/bin/..; /usr/bin/galera_recovery; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR |>
    Process: 1736154 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Main PID: 1736166 (code=exited, status=1/FAILURE)
    Status: "MariaDB server is down"

I give up for now.

Comment by Karl Klepper [ 2021-06-12 ]

Well, stackoverflow came to the rescue: first rm -rf /var/lib/mysql, too.

  1. mysql
    Welcome to the MariaDB monitor. Commands end with ; or \g.
    Your MariaDB connection id is 8
    Server version: 10.4.19-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> select version();
-----------------

version()

-----------------

10.4.19-MariaDB

-----------------
1 row in set (0.000 sec)

MariaDB [(none)]> SHOW VARIABLES LIKE '%plu%';
-----------------------------------------+

Variable_name Value

-----------------------------------------+

plugin_dir /usr/lib64/mysql/plugin/
plugin_maturity gamma

-----------------------------------------+
2 rows in set (0.002 sec)

MariaDB [(none)]> INSTALL SONAME 'ha_sphinx';
Query OK, 0 rows affected (0.002 sec)
To me, this looks like the problem does relate to docker or alpine.

Comment by Karl Klepper [ 2021-06-13 ]

Johan Bergstroem just mailed me:

As I mentioned previously, I think this is by design (not a bug, but intentional). I believe you have the answer here: https://git.alpinelinux.org/aports/tree/main/mariadb/APKBUILD#n162.

So the Alpine-maintainer of MariaDB is in charge? Do I understand correctly the Alpine compiles MariaDB without Sphinx? The error message is by MariaDB, not Alpine, right? And it would be triggered by the omission in the build process?

Comment by Daniel Black [ 2021-06-15 ]

> So the Alpine-maintainer of MariaDB is in charge?

Yes.

> Do I understand correctly the Alpine compiles MariaDB without Sphinx?

Yes.

> The error message is by MariaDB, not Alpine, right?

":errno: 13, Error relocating" is caused by copying around a file that is tightly coupled build process and mariadb version and the dynamic loader not handling it.

> And it would be triggered by the omission in the build process?

Its triggered by YOU, who ignored "Google copy/paste/no analysis/move file X will just end in tears like where you started".

Stop using alpine based containers for sphinxse. It obviously doesn't work. The reasons the official docker image isn't alpine is it isn't actually tested prior to release (https://github.com/MariaDB/mariadb-docker/pull/343), though the alpine maintainers run some tests.

The reasons the official Docker Library mariadb does actually work is because it has sphinx as part of the image already.

Very simple:

$ podman run --name mdb10.4-sphinx-test -d -e MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 mariadb:10.4 --plugin-load-add=ha_sphinx.so
482ec0ef47a7ab89163e187132ecc1d7170d9a034a84c9f5d25af10691d3dea4
 
$ docker exec -ti mdb10.4-sphinx-test mysql -e 'show plugins'
+-------------------------------+----------+--------------------+--------------+---------+
| Name                          | Status   | Type               | Library      | License |
+-------------------------------+----------+--------------------+--------------+---------+
| binlog                        | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| mysql_native_password         | ACTIVE   | AUTHENTICATION     | NULL         | GPL     |
| mysql_old_password            | ACTIVE   | AUTHENTICATION     | NULL         | GPL     |
| wsrep                         | ACTIVE   | REPLICATION        | NULL         | GPL     |
| CSV                           | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| MEMORY                        | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| Aria                          | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| MyISAM                        | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| MRG_MyISAM                    | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| CLIENT_STATISTICS             | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INDEX_STATISTICS              | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| TABLE_STATISTICS              | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| USER_STATISTICS               | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| SQL_SEQUENCE                  | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| InnoDB                        | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| INNODB_TRX                    | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_LOCKS                  | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_LOCK_WAITS             | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_CMP                    | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_CMP_RESET              | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_CMPMEM                 | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_CMPMEM_RESET           | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_CMP_PER_INDEX          | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_CMP_PER_INDEX_RESET    | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_BUFFER_PAGE            | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_BUFFER_PAGE_LRU        | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_BUFFER_POOL_STATS      | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_METRICS                | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_FT_DEFAULT_STOPWORD    | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_FT_DELETED             | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_FT_BEING_DELETED       | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_FT_CONFIG              | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_FT_INDEX_CACHE         | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_FT_INDEX_TABLE         | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_TABLES             | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_TABLESTATS         | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_INDEXES            | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_COLUMNS            | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_FIELDS             | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_FOREIGN            | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_FOREIGN_COLS       | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_TABLESPACES        | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_DATAFILES          | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_VIRTUAL            | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_MUTEXES                | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_SYS_SEMAPHORE_WAITS    | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| INNODB_TABLESPACES_ENCRYPTION | ACTIVE   | INFORMATION SCHEMA | NULL         | BSD     |
| INNODB_TABLESPACES_SCRUBBING  | ACTIVE   | INFORMATION SCHEMA | NULL         | BSD     |
| PERFORMANCE_SCHEMA            | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| SEQUENCE                      | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| unix_socket                   | ACTIVE   | AUTHENTICATION     | NULL         | GPL     |
| FEEDBACK                      | DISABLED | INFORMATION SCHEMA | NULL         | GPL     |
| user_variables                | ACTIVE   | INFORMATION SCHEMA | NULL         | GPL     |
| partition                     | ACTIVE   | STORAGE ENGINE     | NULL         | GPL     |
| SPHINX                        | ACTIVE   | STORAGE ENGINE     | ha_sphinx.so | GPL     |
+-------------------------------+----------+--------------------+--------------+---------+

Replacing podman with docker in the above is exactly the same.

Final notes:

  • Use a officially supported image - https://hub.docker.com/_/mariadb - packaging bugs of anything else don't belong here (though we'll try to address crashes and other bugs).
  • Stop copying around files especially shared libraries and expect them to magicly work (host OS != container OS).
  • Use docker logs containername in bug reports (not used once in this bug report by you)
  • You can't just up/downgrade mariadb 10.1 -> 10.5 and back to 10.4 hence you jumping on a remove the datadir.
  • Slow down and analyze and learn (and much less copy whatever google result returned).
Comment by Karl Klepper [ 2021-06-15 ]

Thank you very much for your patience.

Comment by Karl Klepper [ 2021-06-15 ]

I managed to update my system to use the official mariadb container with little effort.

Thank you for your persistent support and detailed teaching.

Comment by Daniel Black [ 2021-06-16 ]

Glad to hear you managed the migration.

If you are stuck trying to achieve something take note of the "Where to get help" in the Quick Reference https://hub.docker.com/_/mariadb.

Do report bugs/feature requests with the official container here.

Happy MariaDBing.

Generated at Thu Feb 08 09:41:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.