March 2025 - discuss - lists.mariadb.org

Troubleshooting major performance issue.
by Olivier Miquel 30 Mar '25

30 Mar '25

4 11

Processes getting locked out "Opening tables"
by Derick Turner 28 Mar '25

28 Mar '25

Hi all, We have been having some transient issues with processes sticking on the Opening tables state, which means that the total number of processes grows till max processes is hit/locking out the database. OS Ubuntu sever 24.04.02 MariaDB 11.4.5 It appears to be InnoDB deadlocks. So the example today the output from SHOW ENGINE INNODB STATUS \G showed that there was a deadlock between a couple of transactions: MariaDB [(none)]> SHOW ENGINE INNODB STATUS \G *************************** 1. row *************************** Type: InnoDB Name: Status: ===================================== 2025-03-21 12:49:57 0x7200aeae76c0 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 49 seconds ----------------- BACKGROUND THREAD ----------------- srv_master_thread loops: 1541 srv_active, 247133 srv_idle srv_master_thread log flush and writes: 248664 ---------- SEMAPHORES ---------- ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2025-03-18 15:35:00 0x72067aea16c0 *** (1) TRANSACTION: TRANSACTION 57050747951, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 1 MariaDB thread id 17, OS thread handle 125372157531840, query id 101395 *** WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2549335 page no 82714 n bits 320 index mdl_file_pat_uix of table `client1`.`mdl_files` trx id 57050747951 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 40 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 30; hex 393062613639666233633334373364663239333634323134316333303735; asc 90ba69fb3c3473df293642141c3075; (total 40 bytes); 1: len 8; hex 80000000003ac8e3; asc : ;; *** CONFLICTING WITH: RECORD LOCKS space id 2549335 page no 82714 n bits 320 index mdl_file_pat_uix of table `client1`.`mdl_files` trx id 57050747928 lock mode S Record lock, heap no 40 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 30; hex 393062613639666233633334373364663239333634323134316333303735; asc 90ba69fb3c3473df293642141c3075; (total 40 bytes); 1: len 8; hex 80000000003ac8e3; asc : ;; Record lock, heap no 208 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 30; hex 393062613636353139363935316562666532646631636535653238326366; asc 90ba665196951ebfe2df1ce5e282cf; (total 40 bytes); 1: len 8; hex 8000000000b78d51; asc Q;; RECORD LOCKS space id 2549335 page no 82714 n bits 320 index mdl_file_pat_uix of table `client1`.`mdl_files` trx id 57050747951 lock mode S Record lock, heap no 40 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 30; hex 393062613639666233633334373364663239333634323134316333303735; asc 90ba69fb3c3473df293642141c3075; (total 40 bytes); 1: len 8; hex 80000000003ac8e3; asc : ;; Record lock, heap no 208 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 30; hex 393062613636353139363935316562666532646631636535653238326366; asc 90ba665196951ebfe2df1ce5e282cf; (total 40 bytes); 1: len 8; hex 8000000000b78d51; asc Q;; *** (2) TRANSACTION: TRANSACTION 57050747928, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1128, 4 row lock(s), undo log entries 1 MariaDB thread id 20, OS thread handle 125372148479680, query id 101369 Write_rows_log_event::write_row(-1) on table `mdl_files` *** WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2549335 page no 82714 n bits 320 index mdl_file_pat_uix of table `client1`.`mdl_files` trx id 57050747928 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 40 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 30; hex 393062613639666233633334373364663239333634323134316333303735; asc 90ba69fb3c3473df293642141c3075; (total 40 bytes); 1: len 8; hex 80000000003ac8e3; asc : ;; *** CONFLICTING WITH: RECORD LOCKS space id 2549335 page no 82714 n bits 320 index mdl_file_pat_uix of table `client1`.`mdl_files` trx id 57050747928 lock mode S Record lock, heap no 40 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 30; hex 393062613639666233633334373364663239333634323134316333303735; asc 90ba69fb3c3473df293642141c3075; (total 40 bytes); 1: len 8; hex 80000000003ac8e3; asc : ;; Record lock, heap no 208 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 30; hex 393062613636353139363935316562666532646631636535653238326366; asc 90ba665196951ebfe2df1ce5e282cf; (total 40 bytes); 1: len 8; hex 8000000000b78d51; asc Q;; RECORD LOCKS space id 2549335 page no 82714 n bits 320 index mdl_file_pat_uix of table `client1`.`mdl_files` trx id 57050747951 lock mode S Record lock, heap no 40 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 30; hex 393062613639666233633334373364663239333634323134316333303735; asc 90ba69fb3c3473df293642141c3075; (total 40 bytes); 1: len 8; hex 80000000003ac8e3; asc : ;; Record lock, heap no 208 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 30; hex 393062613636353139363935316562666532646631636535653238326366; asc 90ba665196951ebfe2df1ce5e282cf; (total 40 bytes); 1: len 8; hex 8000000000b78d51; asc Q;; *** WE ROLL BACK TRANSACTION (2) I'm assuming that the rest of the processes were waiting on the rollback to happen before they did anything else? So my questions are: Am I right in that? Is there anything which can be done to speed up rollback? Is there anything which can be done to prevent that rollback from blocking all of the other processes, the majority of which were against completely different databases? When I was investigating this the suggestion was to dump and reload all of the databases. We have 221 databases in the cluster which takes up 880GB of filesystem space. A chunk of that is the ibdata1 file which is 290GB on that server. (we now have autoshrink on but only after we'd upgraded to a version which supports it. File per table is on, so much of this is unused space.) We manage this by pointing the webservers to a different node and waiting for the deadlock to clear but I would like to fix it properly. Thanks in advance Derick -- Derick Turner - He/Him

2 12

Allocate CPU, RAM to a MariaDB instance
by jaswanth.at.work＠gmail.com 21 Mar '25

21 Mar '25

We are running multiple instances of mariadb using mysqld_multi on RHEL Server. We want to allocate CPU, RAM based on their individual instance workloads. We had seen that configuring innnodb parameters will do that, but what are the exact parameters we need to configure to allocate CPU Cores, RAM to the specific instance. We want to do it at database level not at OS level. What is the way to do this ?

3 5

Maxscale CLI
by Richard Reina 20 Mar '25

20 Mar '25

I am experimenting with maxscale and have set up a test cluster with a master and three slaves. I have successfully tested automatic failover and everything seems to work fine. However, I will need to run occasional direct read and write SQL queries which in the past have done in a non-maxscale/proxy environment by simply logging into the master and doing select and update queries. Since with Maxscale the master can change I believe I cannot do that. Can someone tell me how I can do SQL queries on the maxscale proxy? How can I get a CLI like: maxscale> UPDATE contact SET inactive='Y' WHERE ID =923;

2 1

Issue with MariaDB eating all the server memory
by Derick Turner 19 Mar '25

19 Mar '25

Hi all, I was pointed to this list from a question I raised on StackExchange (https://dba.stackexchange.com/questions/345743/why-does-my-mariadb-applicat…) I have a cluster of MariaDB (11.4.5) primary/primary servers running on Ubuntu. I updated the OS on Saturday to 24.04 from 22.04 (and patched the DB to the 11.4.5 noble version) as we were occasionally hitting an OOM event which was causing the database process to be killed. Since then, the DB process takes all of the available server memory before being killed by the OOM killer. DB is configured to use about 15GB of RAM (from config calculations) Servers currently have 50GB of RAM and 95% of this is used within about an hour an a half. Link to document with configuration settings, global status, mariadb.service override and InnoDB status is here - https://docs.google.com/spreadsheets/d/1ev9KRWP8l54FpRrhFeX4uxFhJnOlFkV4_vT… Any help would be gratefully received. Thanks in advance. Derick -- Derick Turner - He/Him

6 9

Prevent avalanche of NOTES when importing InnoDB tablespace
by mariadb＠Biblestuph.com 14 Mar '25

14 Mar '25

Greetings, I'm running some tests on MariaDB 11.4.5. When importing table spaces I'm getting a huge number of notifications in the log as follows: 2025-03-14 16:42:57 33 [Note] InnoDB: trying to read page [page id: space=2502, page number=78266] in nonexisting or being-dropped tablespace 2025-03-14 16:42:57 33 [Note] InnoDB: trying to read page [page id: space=2502, page number=78267] in nonexisting or being-dropped tablespace 2025-03-14 16:42:57 33 [Note] InnoDB: trying to read page [page id: space=2502, page number=78268] in nonexisting or being-dropped tablespace The bigger the table, the more messages. Other than taking space they seem harmless, in that the table import appears to work correctly. Is there any way to avoid them? Note that as part of my normal process the table that I'm importing typically exists in the DB prior to the import; if so I drop it (that's the case with the example above). I.E.: DROP TABLE IF EXISTS mydb.t1; (move the remote .frm, .cfg, and .ibd files into the data dir, per https://mariadb.com/kb/en/innodb-file-per-table-tablespaces/) ALTER TABLE mydb.t1 IMPORT TABLESPACE; And the above stream of NOTES appears. I've tried shutting down the DB in-between the DROP and ALTER (with innodb_fastshutdown=0), same result. Am I missing a step somehow? Thanks for any assistance! Dan

1 0

Re: Mariadb-dump, backing up single partition
by pslawek83 13 Mar '25

13 Mar '25

Hi Sergei, thanks for the comment. Currently tried to just add very simple change which will allow the user to specify partition name using comma separated list and a separator in table's name. For example ./mariadb-dump -umyuser -pmypass -h127.0.0.1 mydatabase _test1@p0,p1 _test2@p0 --partition-separator=@, not sure if I should parse the partition string to ensure there's no syntax error in generated query and partition names are escaped? Maybe will add ability to do that in parallel, automatically when i'll become more familiar with the framework. Thanks, Slawomir. Dnia 12 marca 2025 13:11 Sergei Golubchik <serg(a)mariadb.org> napisał(a): Hi, pslawek83, Note that mariadb-dump already supports --parallel option that can dump many tables in parallel. Depending on your use case you might want to extend --parallel to automatically dump individual partitions in parallel, instead of extending mariadb-dump to allow to specify what partition to dump. Depends on what you need, of course, I'm just listing the options so that you could choose what works better for you. On Mar 12, pslawek83 via discuss wrote: Hi Everyone, I want to add the ability to backup a single partition using mysqldump. I have some large (500GB+) partitioned tables I want to backup fast. So the idea is to run each partition in parallel using mariadb-dump but AFAIK there&#39;s no option for specifying the partition yet. Will you merge my code if I add that to mariadb-dump ? I assume MariaDB/server/blob/main/client/mysqldump.cc is where dev for that happens? Thanks Regards, Sergei Chief Architect, MariaDB Server and security(a)mariadb.org

1 0

Mariadb-dump, backing up single partition
by pslawek83 12 Mar '25

12 Mar '25

Hi Everyone, I want to add the ability to backup a single partition using mysqldump. I have some large (500GB+) partitioned tables I want to backup fast. So the idea is to run each partition in parallel using mariadb-dump but AFAIK there's no option for specifying the partition yet. Will you merge my code if I add that to mariadb-dump ? I assume MariaDB/server/blob/main/client/mysqldump.cc is where dev for that happens? Thanks

3 2

For 10.4.x holdouts - 10.4.34.1
by Gordan Bobic 09 Mar '25

09 Mar '25

For anyone else here who doesn't particularly want to move to 10.5 or 10.6 quite yet, here's a build for el8 and el9 that includes a backport of fix for CVE-2025-21490 https://dl.shatteredsilicon.net/MariaDB/ -- Gordan Bobic Database Specialist, Shattered Silicon Ltd. https://shatteredsilicon.net

1 0