- discuss - lists.mariadb.org

MariaDB on StackExchange
by Otto Kekäläinen 06 Jun '25

06 Jun '25

Hi, This was news to me, so I thought I'd share that there are quite a few posts on tag 'mariadb' at https://dba.stackexchange.com/questions/tagged/mariadb People on this discussion list might want to participate in similar discussions at DBA StackExchange too. - Otto PS. If you like MariaDB, show your support and help it get to 10k stars at https://github.com/MariaDB/Server

2 1

Re: haproxy mysql-check user not working
by vbvbrj 06 Jun '25

06 Jun '25

On 06.06.2025 11:19, Markus Mäkelä wrote: > > Hi, > > If you're interested, you could try out MariaDB MaxScale that's > designed for proxying database connections. The 21.06 version is > available under GPLv2 if you want to try it with no strings attached: > https://mariadb.com/kb/en/mariadb-maxscale-21-06/ > > Markus > As I understand this is an alternative to ProxySql. The good thing this is from same developers and tables for users are from mariadb server itself. ProxySql hase separate authentication table on its one besides autentication table in mariadb. But really is a good balancing alternative.

1 0

haproxy mysql-check user not working
by vbvbrj 06 Jun '25

06 Jun '25

Hello. mariadb 11.8.1 I want to use haproxy with check option. Using in haproxy `option mysql-check` works but maridb logs: [Warning] Aborted connection 24971 to db: 'unconnected' user: 'unauthenticated' host: '10.0.1.165' (This connection closed normally without authentication) This is confusing as I don't know that this is regular check from haproxy, or someone tried to connect. So I want to use in haproxy `option mysql-check user haproxy-check post-41`. But this fails with error: [Warning] Access denied for user 'haproxy-check'@'10.0.1.164' (using password: NO) and haproxy shows the mariadb server as DOWN. Because in haproxy there is no way to specify a password for the user to connect to the instance of mariadb, I tried to allow passwordless access for the haproxy-check user from the specified network and minimum grants. But this does not help to allow access without password. Tried also to allow access for this user from any host and givin full access and also authentication fails. Is there an option in mariadb that does not allow paswordless authentication?

2 2

Galera Cluster (MariaDB 10.6.15) – Severe INSERT/UPDATE Delay and DB Shutdown due to dict_sys.latch
by idstevemg＠gmail.com 04 Jun '25

04 Jun '25

■ Environment ●Cluster: Galera Cluster (3 nodes) ●OS: CentOS 7.4 ●DBMS: MariaDB 10.6.15 ●DB Uptime: 509 days ■ Issue Overview ●Time of Occurrence: Between 00:00 and 02:00 ●Initial Symptom: Single-row INSERT and DELETE queries were delayed by several seconds and eventually stalled ●Around 00:34: Massive UPDATE queries (targeting same PK) led to X locks and an increase in active sessions ●00:35: CPU usage on DB server hit 100% and stayed at critical levels; thread count spiked ●00:41: Galera node DB01 shut down automatically Error log excerpt: [ERROR][FATAL] InnoDB: innodb_fatal_semaphore_wait_threshold for dict_sys.latch was exceeded. See : https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ ■ Root Cause (Internal Analysis) ●dict_sys.latch exceeded the innodb_fatal_semaphore_wait_threshold (default: 600 seconds) ●This caused InnoDB to forcefully kill the MariaDB process ●The dict_sys.latch is a global latch for the InnoDB data dictionary, which can become a severe bottleneck under high concurrency ❗ What’s Unusual: ●No clear sign of typical row locks or massive spike in transaction volume ●Even single-row INSERT and DELETE queries were delayed by thousands of seconds, which is highly abnormal ●No obvious external factors (lock contention, CPU saturation, or connection floods) were identified ●Strong suspicion of internal engine behavior or a bug ❓ Questions and Request for Input ●Has anyone experienced a similar issue related to dict_sys.latch in Galera Cluster environments? ●Are there known bugs or release notes in MariaDB 10.6.x or Galera that mention severe delays or process termination related to this latch? ●Any known workarounds or best practices to prevent this from recurring? Your experience and advice would be greatly appreciated. Thank you in advance!

1 0

Request to Adapt VIDEX (Virtual Index for what-if Analysis) for MariaDB
by 康荣 03 Jun '25

03 Jun '25

Dear MariaDB Community, I hope this message finds you well. We'd like to introduce VIDEX (Virtual Index for MySQL) and humbly seek your guidance and assistance in adapting it for MariaDB compatibility. We've developed a virtual index storage engine (plugin) called VIDEX. It can simulate the impact of indexes on query plan costs without requiring real data. VIDEX forwards the statistical information, ndv (records_per_key), and cardinality information (records_in_range) needed for making query plans via a RESTful approach, with responses provided by an "algorithm service." This disaggregated design is particularly well-suited for integrating various AI-boosted cardinality and ndv algorithms. VIDEX has been successfully deployed at ByteDance, serving thousands of MySQL instances daily and over millions of SQL queries for index optimization tasks. We implemented VIDEX based on MySQL 8.0 and now, thanks to Federico Razzoli for his suggestion (LinkedIn post 1 <https://www.linkedin.com/feed/update/urn:li:activity:7307955728613351424/>, LinkedIn post 2 <https://www.linkedin.com/posts/federicorazzoli_github-bytedancevidex-virtua…>, , Github Issue <https://github.com/bytedance/videx/issues/1>), we'd like to adapt it to MariaDB. However, we've discovered significant differences between MySQL 8.0 and the latest MariaDB codebase. Therefore, we're seeking help from the MariaDB community, and would greatly appreciate collaboration with experienced developers to modify the code. We're very willing to cooperate in this effort. In the future, we also hope to have the opportunity to add VIDEX to the official MariaDB plugin list. *About VIDEX* VIDEX GitHub repository: https://github.com/bytedance/videx/ Virtual index technology is already available in PostgreSQL, Oracle, and IBM DB2, and would provide MariaDB users with valuable capabilities for query optimization and database research. VIDEX offers key features that would benefit MariaDB users: - What-if analysis for index strategies without production impact - Support for integration of custom or AI-based estimation algorithms - Accurate simulation of query plans, verified with complex benchmarks like TPC-H and JOB If you're interested in collaborating or have guidance to offer on adapting our code to MariaDB, we'd greatly appreciate hearing from you. Thank you for your consideration. Best regards, Rong ByteBrain Team, Bytedance

7 20

(JOB) Denmark DBA
by James Tobin 03 Jun '25

03 Jun '25

Hello, I am working with an employer that is looking to hire a MySQL DBA in Denmark. Please reach me using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

1 0

reoccuring DB corruption we don't understand
by sacawulu 02 Jun '25

02 Jun '25

Hi, We are seeing recurrent corruption on one of our DB nodes, running RHEL9, under vmware, MariaDB 10.11.10. > 2025-05-13 6:32:08 0 [ERROR] InnoDB: tried to purge non-delete-marked record in index `cardChipNumber` of table `mydb`.`idm_usc_kaart_status`: tuple: TUPLE (info_bits=0, 2 fields): {[17]36147687118764292(0x3336313437363837313138373634323932),[4] " (0x9722A2FB)}, record: COMPACT RECORD(info_bits=0, 2 fields): {[17]36147687118764292(0x3336313437363837313138373634323932),[4] " (0x9722A2FB)} > 2025-05-13 6:32:08 0 [ERROR] InnoDB: Flagged corruption of `cardChipNumber` in table `mydb`.`idm_usc_kaart_status` in purge > 2025-05-13 10:39:20 442752 [ERROR] Got error 180 when reading table './mydb/idm_usc_kaart_status' > 2025-05-13 12:44:51 0 [ERROR] InnoDB: tried to purge non-delete-marked record in index `inschrijving_id` of table `mydb`.`tinschrijving`: tuple: TUPLE (info_bits=0, 2 fields): {[4] ](0x800D0C5D),[4] \Y[(0x805C595B)}, record: COMPACT RECORD(info_bits=0, 2 fields): {[4] ](0x800D0C5D),[4] \Y[(0x805C595B)} > 2025-05-13 12:44:51 0 [ERROR] InnoDB: Flagged corruption of `inschrijving_id` in table `mydb`.`tinschrijving` in purge > 2025-05-13 12:45:59 453516 [ERROR] Got error 180 when reading table './mydb/tinschrijving' > 2025-05-13 12:46:03 453524 [ERROR] Got error 180 when reading table './mydb/tinschrijving' > 2025-05-13 12:46:21 453540 [ERROR] Got error 180 when reading table './mydb/tinschrijving' > 2025-05-13 12:46:26 453541 [ERROR] Got error 180 when reading table './mydb/tinschrijving' and last thursday suddenly again: > 2025-05-29 6:32:22 290727 [ERROR] Got error 180 when reading table './mydb/idm_usc' It starts without an obvious (to us) reason. We have verified that we are running (with what seems to be) safe settings, like: innodb_doublewrite = ON and innodb_flush_method = O_DIRECT | The system has enough ram, swap configured but none in use, no full disks/partitions. At a certain moment (after may 13) it became so bad, that I took a full mysqldump of all DB's: > mysqldump --all-databases --single-transaction --routines --triggers --events > /mnt/sdc/full_admin_backup.sql emptied the datadir, and imported it all fresh again: > mysql < /mnt/sdc/full_admin_backup.sql And to my surprise, last week thursday, it happened again. Filesystem is xfs, mounted like: > /dev/sdb on /data type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) No fs corruption detected checked with > xfs_scrub /data and > xfs_spaceman -c 'health -c ' /data/ | grep -v ok We are unsure what causes this. It should not be possible (I guess?) for userspace / php scripts (this is LAMP setup) to cause issues like this. We are unsure how to further troubleshoot. Anyone with valuable suggestions or insights? Or more information required..? Thanks in advance! MJ

1 0

After upgrade from 10.11.11 to 10.11.13, Mariadb will not start with the existing SSL certs.
by Simon Avery 27 May '25

27 May '25

Hello, (Not reporting as a bug immediately; looking for confirmation and advice before doing so as it feels like this would be more widely reported if others are affected.) Several of our Mariadb servers failed to return after regular patching this morning after Mariadb upgraded from 10.11.11 to 10.11.13. Looks like, after being happy with the SSL keys for over six months, Mariadb suddenly doesn't like them. This looks like something has changed in Mariadb in this version that is stopping it reading our SSL keys, but I cannot see anything in the release notes relating to changes to SSL for .12 or .13 https://mariadb.com/kb/en/mariadb-10-11-13-changelog/ Workings: Patching immediately before updated from 10.11.11to 10.11.13. No other updates applied apart from zabbix-agent). VMs are running Rocky 9. Upgrading: MariaDB-client x86_64 10.11.13-1.el9 mariadb_10.11_r9 9.3 M MariaDB-common x86_64 10.11.13-1.el9 mariadb_10.11_r9 88 k MariaDB-server x86_64 10.11.13-1.el9 mariadb_10.11_r9 18 M MariaDB-shared x86_64 10.11.13-1.el9 mariadb_10.11_r9 131 k Before patching, mariadb was using one-sided SSL with self-signed SSL certs. Everything working as expected, been in place for over six months. After Maria upgraded from 10.11.11 to .13, Mariadb will not start. 250526 6:38:03 server_audit: logging started to the syslog. SSL error: Unable to get private key from '/etc/my.cnf.d/ssl/server-key.pem' 2025-05-26 6:38:03 0 [ERROR] Failed to setup SSL 2025-05-26 6:38:03 0 [ERROR] SSL error: Unable to get private key 2025-05-26 6:38:03 0 [ERROR] Aborting server-key.pem looks okay, starts "-----BEGIN RSA PRIVATE KEY-----" - privs are 700, owned by mysql user, turning off selinux doesn't fix it. File date six months old (it's a year long key with checks to renew at -30d), and openssl likes it; # openssl rsa -in server-key.pem -check RSA key ok writing RSA key -----BEGIN RSA PRIVATE KEY----- My temporary fix is removing this from the config and then mariadb will restart. Fortunately are clients don't require SSL. [mysqld] #ssl-ca=/etc/my.cnf.d/ssl/ca-cert.pem #ssl-cert=/etc/my.cnf.d/ssl/server-cert.pem #ssl-key=/etc/my.cnf.d/ssl/server-key.pem Thank you

2 3

ODBC driver and SQLDescribeParam()
by Volker Wysk 26 May '25

26 May '25

Hi! I'm working on a high-level database access library, using UnixODBC, MariaDB and the MariaDB-ODBC-driver. I's for the Mercury programming language. The MariaDB ODBC 3.1.4 Driver doesn't work when using SQLDescribeParam(). This ODBC function is used to query metadata for the parameters of a prepared SQL statement (one which includes question marks). Such as the type of the parameter. The driver returns SQL_VARCHAR for all parameters, regardless of the actual type of the parameter. I've installed and tried the newest MariaDB ODBC 3.2.5 Driver, and there's no difference. It also reports SQL_VARCHAR for all parameters. But I'm not 100% sure I've installed the newer driver correctly. What is the state of affairs about MariaDB and ODBC parameter metadata? Thanks, Volker

2 2

[Maria-discuss] Galera 23.2.7 mariadb 5.5.33a msvc 1600 binaries available
by Yann Nayn 21 May '25

21 May '25

Binaries have been uploaded for both x86 and amd64 platforms. due to github file size limitations , the directories have been uploaded unarchived. for Win33 binaries , please checkout https://github.com/YannNayn/galera-mariadb-win32.git and for Win64(amd64) binaries (being uploaded/pushed): https://github.com/YannNayn/galera-mariadb-win64.git they are not recommended for a production environment. in the my.cnf file: _________ wsrep_provider=galera_smm.dll wsrep_sst_method=msqldump # percona xtrabackup will be tested soon _________ libevent and openssl(the provided binaries use respectively 2.1.3-alpha and 1.1.0-dev versions ) will be added next on github some limitations are stated on openssl website copied here for convenience: ____________ from http://www.openssl.org/ ____________ This software package uses strong cryptography, so even if it is created, maintained and distributed from liberal countries in Europe (where it is legal to do this), it falls under certain export/import and/or use restrictions in some other parts of the world. PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS OF OPENSSL ARE NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY. ________________________________________________ msvc 1600 redistributables SP1 need to be installed/available on the target machine: vcredist_x86.exe : http://www.microsoft.com/en-us/download/details.aspx?id=8328 vcredist_x64.exe : http://www.microsoft.com/en-us/download/details.aspx?id=13523 MSys binaries are provided and msqld.bat should then be used instead of mysqld.exe (e.g. mysld.bat --console --wsrep_cluster_address=gcomm:// ) in order to have a working sh shell(cygwin has been proved to do it as well) Please note that oqgraph is disabled (boost trunk is used , that is 1.55) Comments and suggestions are welcome.

5 4