Switching to a newer LTS version which brings improvements: https://mariadb.com/kb/en/what-is-mariadb-114/
This update brings major improvements in DB optimizer. This should speedup queries, even delete and update queries, which uses joins. Also other components like JSON, InnoDB or ALTER Table statements have been improved. For details see the changelog. References: https://mariadb.com/kb/en/what-is-mariadb-114/ ======================== Updated packages in core/updates_testing: ======================== mariadb-client-debuginfo-11.4.5-1.mga9 mariadb-client-11.4.5-1.mga9 lib64mariadbd19-11.4.5-1.mga9 lib64mariadb-embedded-devel-11.4.5-1.mga9 mariadb-core-11.4.5-1.mga9 lib64mariadb-devel-11.4.5-1.mga9 mariadb-mroonga-debuginfo-11.4.5-1.mga9 mariadb-rocks-11.4.5-1.mga9 mariadb-common-11.4.5-1.mga9 mariadb-spider-debuginfo-11.4.5-1.mga9 mariadb-mroonga-11.4.5-1.mga9 mariadb-connect-debuginfo-11.4.5-1.mga9 mariadb-bench-debuginfo-11.4.5-1.mga9 mariadb-s3-engine-11.4.5-1.mga9 mariadb-s3-engine-debuginfo-11.4.5-1.mga9 mariadb-spider-11.4.5-1.mga9 mariadb-feedback-debuginfo-11.4.5-1.mga9 mariadb-connect-11.4.5-1.mga9 mariadb-sphinx-debuginfo-11.4.5-1.mga9 mariadb-11.4.5-1.mga9 mariadb-extra-debuginfo-11.4.5-1.mga9 mariadb-obsolete-debuginfo-11.4.5-1.mga9 lib64mariadb3-debuginfo-11.4.5-1.mga9 mariadb-common-core-11.4.5-1.mga9 lib64mariadb3-11.4.5-1.mga9 mariadb-sequence-debuginfo-11.4.5-1.mga9 mariadb-extra-11.4.5-1.mga9 mariadb-sphinx-11.4.5-1.mga9 mariadb-obsolete-11.4.5-1.mga9 mariadb-pam-11.4.5-1.mga9 mariadb-pam-debuginfo-11.4.5-1.mga9 mariadb-sequence-11.4.5-1.mga9 mariadb-feedback-11.4.5-1.mga9 mysql-MariaDB-11.4.5-1.mga9 lib64mariadb-devel-debuginfo-11.4.5-1.mga9 mariadb-debuginfo-11.4.5-1.mga9 mariadb-debugsource-11.4.5-1.mga9 lib64mariadbd19-debuginfo-11.4.5-1.mga9 mariadb-core-debuginfo-11.4.5-1.mga9 mariadb-bench-11.4.5-1.mga9 mariadb-common-debuginfo-11.4.5-1.mga9 mariadb-rocks-debuginfo-11.4.5-1.mga9 lib64mariadb-embedded-devel-debuginfo-11.4.5-1.mga9 SRPM: mariadb-11.4.5-1.mga9.src.rpm
Assignee: mageia => qa-bugs
CC: (none) => mageia
Installation had no issues. Testing revealed two minor issues and one issue specific to my setup. The following message shows the first of the minor issues: """ abr 09 11:41:55 marte mysqld[7098]: /usr/sbin/mysqld: Deprecated program name. It will be removed in a future release, use '/usr/sbin/mariadbd' instead """ The following message shows the second of the minor issues: """ # mysql_upgrade --skip-write-binlog mysql_upgrade: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-upgrade' instead """ These minor issues are simple to solve but it may be a good idea to show a notice during install/update indicating the changes, especially if the systemd service is also rename. The following issue is specific to my setup but I will describe it in case someone has the same issue. I restrict the mysqld/mariadb service with some extra systemd directives, in particular the SystemCallFilter directive. It seems this update tries to use the chown system call while the previous version didn't. Since the chown was being blocked by the SystemCallFilter directive, I had to change it to allow chown. Thus I added "@chown" to the SystemCallFilter directive, as seen in the next line: SystemCallFilter=@system-service @chown For now, this update seems to be working without issues. I will make a full report in a few days of use, and some extensive testing.
@PC LX at the moment, I'd like to keep the service running as mysqld, as changing this could lead to problems during update or running systems. The warnings are enough I think - for the output during install, I've changed the commands I'm not familiar with SystemCallFilter, if this is safe to set, I can add this to our general service definition.
added SystemCallFilter and pushed a new build. I have to wait for the result too, as it takes too long to build it locally
Below are the extra systemd directives I have in /etc/systemd/system/mysqld.service.d/override.conf The rest of my mariadb setup is the default with the exception of having "skip-networking". These work well for me. Still, to be included as the default I would recommend some extensive testing first. """""""""""""""""""""""""""""""""""""" # If "skip-networking" is set in the configuration then "AF_INET AF_INET6" # should be removed from RestrictAddressFamilies and PrivateNetwork=should # be set to "yes". [Service] PrivateNetwork=yes PrivateUsers=yes PrivateTmp=yes PrivateDevices=yes DevicePolicy=closed UMask=0077 NoNewPrivileges=yes LockPersonality=yes MemoryDenyWriteExecute=yes RemoveIPC=yes RestrictRealtime=yes RestrictSUIDSGID=yes RestrictNamespaces=yes RestrictAddressFamilies=AF_UNIX #RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 SystemCallArchitectures=native SystemCallFilter=@system-service @chown SystemCallFilter=~ @privileged @resources ProtectHome=yes ProtectHostname=yes ProtectKernelLogs=yes ProtectClock=yes ProtectControlGroups=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectKernelLogs=yes ProtectSystem=strict AmbientCapabilities= CapabilityBoundingSet= StateDirectory=mysql RuntimeDirectory=mysqld LogsDirectory=mysqld """"""""""""""""""""""""""""""""""""""
Ok, I see you are an systemd expert. Maybe I can include some of the for the next release. Already installed this version in production - on my systems I get less slow queries than before.
MGA9-64 Plasma XWayland on Compaq H000SB No installatiion issues, omitting all debug stuff. # systemctl start httpd # systemctl start mysqld takes a rather unusual long time to return, but OK. # systemctl -l status mysqld ● mysqld.service - MySQL database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; preset: disabled) Active: active (running) since Fri 2025-04-11 11:29:24 CEST; 1min 36s ago Process: 4030 ExecStartPre=/usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS) Main PID: 4163 (mysqld) Status: "Taking your SQL requests now..." Tasks: 19 (limit: 8806) Memory: 180.2M CPU: 23.182s CGroup: /system.slice/mysqld.service └─4163 /usr/sbin/mysqld Apr 11 11:28:51 mach3.hviaene.thuis mysqld[4163]: 2025-04-11 11:28:51 0 [Note] InnoDB: log sequence number 47629; transaction id 14 Apr 11 11:28:51 mach3.hviaene.thuis mysqld[4163]: 2025-04-11 11:28:51 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool Apr 11 11:28:51 mach3.hviaene.thuis mysqld[4163]: 2025-04-11 11:28:51 0 [Note] CONNECT: Version 1.07.0002 March 22, 2021 Apr 11 11:28:51 mach3.hviaene.thuis mysqld[4163]: 250411 11:28:51 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED. Apr 11 11:28:51 mach3.hviaene.thuis mysqld[4163]: 250411 11:28:51 server_audit: Query cache is enabled with the TABLE events. Some table reads can be veiled> Apr 11 11:28:51 mach3.hviaene.thuis mysqld[4163]: 2025-04-11 11:28:51 0 [Note] InnoDB: Buffer pool(s) load completed at 250411 11:28:51 Apr 11 11:29:24 mach3.hviaene.thuis mysqld[4163]: 2025-04-11 11:29:24 0 [Note] mysqld: Event Scheduler: Loaded 0 events Apr 11 11:29:24 mach3.hviaene.thuis mysqld[4163]: 2025-04-11 11:29:24 0 [Note] /usr/sbin/mysqld: ready for connections. Apr 11 11:29:24 mach3.hviaene.thuis mysqld[4163]: Version: '11.4.5-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 0 Mageia MariaDB Server Apr 11 11:29:24 mach3.hviaene.thuis systemd[1]: Started mysqld.service. Installed phpmyadmin with urpmi, because MCC would draw in php8.3 from backports. This looks like a first install, although this laptop had already mariadb10, so used # mysql_secure_installation to get going. Then used phpmyadmin to create a new database, create a new table with primary and unique key, char field and a timestam. Populated with some data, all worked OK.
CC: (none) => herman.viaene
If no one else jumps in, give it the go.
Keywords: (none) => advisory
Installed and tested for 3 days without issues. Tested with: - mysql CLI; - dbeaver-ce; - mysql workstation; - PHP scripts (e.g. phpmyadmin, wordpress, drupal, roundcubemail, nextcloud); - Qt6 applications using the QSqlMySql plugin driver; - network access disabled, only using unix socket. - systemd restricted service for improved security (see comment 5). All OK. Giving it the OK for x86_64. System: Mageia 9, x86_64, Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz. $ uname -a Linux marte 6.6.83-server-1.mga9 #1 SMP PREEMPT_DYNAMIC Sun Mar 16 03:13:31 UTC 2025 x86_64 GNU/Linux $ rpm -qa | grep mariadb | sort lib64mariadb3-11.4.5-1.mga9 mariadb-11.4.5-1.mga9 mariadb-client-11.4.5-1.mga9 mariadb-common-11.4.5-1.mga9 mariadb-common-core-11.4.5-1.mga9 mariadb-core-11.4.5-1.mga9 mariadb-extra-11.4.5-1.mga9 $ systemctl status mysqld.service ● mysqld.service - MySQL database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; preset: disabled) Drop-In: /etc/systemd/system/mysqld.service.d └─override.conf Active: active (running) since Sat 2025-04-12 10:00:07 WEST; 3min 5s ago Process: 2202828 ExecStartPre=/usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS) Main PID: 2202842 (mysqld) Status: "Taking your SQL requests now..." Tasks: 17 (limit: 19018) Memory: 281.9M CPU: 6.968s CGroup: /system.slice/mysqld.service └─2202842 /usr/sbin/mysqld abr 12 10:00:05 marte systemd[1]: Starting mysqld.service... abr 12 10:00:05 marte mysqld[2202842]: /usr/sbin/mysqld: Deprecated program name. It will be removed in a future release, use '/usr/sbin/mariadbd' instead abr 12 10:00:05 marte mysqld[2202842]: 2025-04-12 10:00:05 0 [Warning] failed to retrieve the MAC address abr 12 10:00:07 marte systemd[1]: Started mysqld.service.
Whiteboard: (none) => MGA9-64-OK
(In reply to Marc Krämer from comment #4) > added SystemCallFilter and pushed a new build. I have to wait for the result > too, as it takes too long to build it locally I'm confused. Does this comment about a "new build" mean another round of testing will be needed? The version numbers tested in comment 9 are the same as in comment 1. I would expect a "new build" to have a different version number.
CC: (none) => andrewsfarm
I've done the rebuild for mariadb-11.4.5-1.mga9.src.rpm on 2025-04-09 15:48. The changes were a warning during install for the changed name, also for the scripts we use internally use the maria name instead mysql to supress those warnings and at last the changes inside systemd file. Since Herman tested after I've done the rebuild, he must have tested the new version.
I tested packages with version 11.4.5-1.mga9 but now there are new packages with version 11.4.5-2.mga9 in the core_update/testing repository. Should I test the new ones?
binaries are unmodified, just the changes I mentioned. They are the result from your feedback.
@PC LX: Sounds to me like it's probably not necessary - but it couldn't hurt. @katnatek: Please make sure the advisory reflects the correct version.
(In reply to Thomas Andrews from comment #14) > @PC LX: Sounds to me like it's probably not necessary - but it couldn't hurt. > > @katnatek: Please make sure the advisory reflects the correct version. Done!
Updated to the version 11.4.5-2.mga9. No issues after about a day of use. Since this is a minor change from the 11.4.5-1.mga9, I think this is enough testing. $ rpm -qa | grep mariadb | sort lib64mariadb3-11.4.5-2.mga9 mariadb-11.4.5-2.mga9 mariadb-client-11.4.5-2.mga9 mariadb-common-11.4.5-2.mga9 mariadb-common-core-11.4.5-2.mga9 mariadb-core-11.4.5-2.mga9 mariadb-extra-11.4.5-2.mga9
Thank you. Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2025-0039.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Hi, When updating a production server, mariadb don't restart due to the lack of "mysqld-prepare-db-dir" uses by the previous systemd unit (see comment #7 & #9) Idea : create a symbolic link with "mariadb-prepare-db-dir" A RPM update would be useful. Thx
CC: (none) => richard
(In reply to rexy from comment #19) > Hi, > When updating a production server, mariadb don't restart due to the lack of > "mysqld-prepare-db-dir" uses by the previous systemd unit (see comment #7 & > #9) > > Idea : create a symbolic link with "mariadb-prepare-db-dir" > > A RPM update would be useful. Thx Please open a new report
Done : https://bugs.mageia.org/show_bug.cgi?id=34200