- discuss - lists.mariadb.org

Issue on upgrading Mariadb 11.4.5 to 11.4.7 on Ubuntu 24.04
by Derick Turner 07 Jun '25

07 Jun '25

Hi all, Patching one of our spare servers this morning and ran into a couple of issues. The first was a complaint in the service status: mariadb.service: Referenced but unset environment variable evaluates to an empty string: MYSQLD_OPTS, _WSREP_NEW_CLUSTER Which was fixed by running systemctl edit mariadb.service and adding Environment="MYSQLD_OPTS=" Environment="_WSREP_NEW_CLUSTER=" to the end of the file. The second was from the error log which stated that the service was unable to read /etc/mysql/rest/keyfile.passwd, which turned out to be a permissions error on /etc/mysql/rest which was 600 and not 700 (I checked the other servers and theirs were also 600 so I guess it's the fix for MDEV-36229 which caused that) Now the server starts but it core dumps almost immediately. Systemctl status shows: ● mariadb.service - MariaDB 11.4.7 database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: enabled) Drop-In: /etc/systemd/system/mariadb.service.d └─migrated-from-my.cnf-settings.conf, override.conf Active: activating (auto-restart) (Result: core-dump) since Sat 2025-06-07 12:45:30 UTC; 1s ago Docs: man:mariadbd(8) https://mariadb.com/kb/en/library/systemd/ Process: 26495 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS) Process: 26497 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Process: 26500 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS) Process: 26684 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=dumped, signal=SEGV) Main PID: 26684 (code=dumped, signal=SEGV) CPU: 1.136s and error log shows 2025-06-07 12:33:57 0 [Note] Starting MariaDB 11.4.7-MariaDB-ubu2404-log source revision 118cfcf82107188f2295631193658b2ef94f4f3f server_uid 7bAWQJ3wkO2Wd/rTUTlrW6jyD3E= as process 4209 2025-06-07 12:33:57 0 [Note] InnoDB: Compressed tables use zlib 1.3 2025-06-07 12:33:57 0 [Note] InnoDB: Number of transaction pools: 1 2025-06-07 12:33:57 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2025-06-07 12:33:57 0 [Note] InnoDB: Using liburing 2025-06-07 12:33:57 0 [Note] InnoDB: innodb_buffer_pool_size_max=22528m, innodb_buffer_pool_size=22528m 2025-06-07 12:33:58 0 [Note] InnoDB: Initialized memory pressure event listener 2025-06-07 12:33:58 0 [Note] InnoDB: Completed initialization of buffer pool 2025-06-07 12:33:58 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes) 2025-06-07 12:33:58 0 [Note] InnoDB: Resetting space id's in the doublewrite buffer 2025-06-07 12:33:58 0 [Note] InnoDB: End of log at LSN=43439159458895 2025-06-07 12:33:58 0 [Note] InnoDB: Opened 3 undo tablespaces 2025-06-07 12:33:58 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active. 2025-06-07 12:33:58 0 [Warning] InnoDB: Cannot free the unused segments in system tablespace because a previous shutdown was not with innodb_fast_shutdown=0 or XA PREPARE transactions exist 2025-06-07 12:33:58 0 [Note] InnoDB: System tablespace defragmentation process starts 2025-06-07 12:33:58 0 [Note] InnoDB: Moving the data from extents 15552 through 2452672 250607 12:33:58 [ERROR] /usr/sbin/mariadbd got signal 11 ; Sorry, we probably made a mistake, and this is a bug. Your assistance in bug reporting will enable us to fix this for the next release. To report this bug, see https://mariadb.com/kb/en/reporting-bugs about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.4.7-MariaDB-ubu2404-log source revision: 118cfcf82107188f2295631193658b2ef94f4f3f The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x0 stack_bottom = 0x0 thread_stack 0x30000 /usr/sbin/mariadbd(my_print_stacktrace+0x30)[0x5a41189db560] /usr/sbin/mariadbd(handle_fatal_signal+0x2a1)[0x5a4118574ae1] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7650bf845330] /usr/sbin/mariadbd(+0x636615)[0x5a41180bb615] /usr/sbin/mariadbd(+0x1043036)[0x5a4118ac8036] /usr/sbin/mariadbd(+0xec468d)[0x5a411894968d] /usr/sbin/mariadbd(+0x622c5a)[0x5a41180a7c5a] /usr/sbin/mariadbd(+0xd9b926)[0x5a4118820926] /usr/sbin/mariadbd(_Z24ha_initialize_handlertonPv+0x8c)[0x5a411857717c] /usr/sbin/mariadbd(+0x8165b3)[0x5a411829b5b3] /usr/sbin/mariadbd(+0x8167a7)[0x5a411829b7a7] /usr/sbin/mariadbd(_Z11plugin_initPiPPci+0xbfc)[0x5a41182a1e3c] /usr/sbin/mariadbd(+0x6bbd65)[0x5a4118140d65] /usr/sbin/mariadbd(_Z11mysqld_mainiPPc+0xf79)[0x5a4118144f79] /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x7650bf82a1ca] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x7650bf82a28b] /usr/sbin/mariadbd(_start+0x25)[0x5a411811e865] Writing a core file... Working directory at /var/lib/mysql Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max processes 139959 139959 processes Max open files 1048576 1048576 files Max locked memory 524288 524288 bytes Max pending signals 139959 139959 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E Kernel version: Linux version 6.8.0-60-generic (buildd@lcy02-amd64-054) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #63-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 19:04:15 UTC 2025 Is there anything I'm missing before I raise this as a bug? Kind regards Derick -- Derick Turner - He/Him Managing Director e-Learn Design Ltd | Scotland's Moodle Partner T +44 (0)845 474 4512 | M +44 (0)7808 068 797 |www.e-learndesign.co.uk

2 3

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

10.11.8 writing all binary logs in row format (even though format is MIXED)
by mariadb＠Biblestuph.com 14 May '25

14 May '25

Doing a little fishing here ... Does someone know of a reason why a downstream replica would--seemingly spontaneously--start writing ALL of its binary log entries in ROW format, even though binlog_format is MIXED? This replica has been running for quite some time, though admittedly I had to restore it from a backup about 3 weeks ago as the result of a server crash. But it had been writing data fine over those three weeks (and prior); starting on March 2nd it started writing all of its entries in ROW format. I didn't notice until it filled the disk this morning. I can't think of anything that may have changed at that time. Normally a few entries will get written as ROW but most are definitely MIXED in normal operation. I stopped/restarted it this morning and it's writing in MIXED again, as expected. I also checked the upstream primary, it is _not_ writing its records as ROW. I.E., my replica is (apparently) not getting them that way from upstream. Both are 10.11.8. Any ideas? TIA, Dan

2 7

query optimization
by Jaco Kroon 06 May '25

06 May '25

Hi All, So I'm stuck with an application that does something like (can't trivially modify the code): Prepare SELECT * FROM view_name WHERE id = ? Execute SELECT * FROM view_name WHERE id = 'p1-p2' The problem is that id is a compound between two individual indexes from the underlying tables, eg: CREATE VIEW AS SELECT CONCAT(k1, '-', k2) id, other, fields FROM table1, table2; Yes, the full join is on purpose, table2 will only ever have a handful (three currently) rows in it. table1 however can get "big" (only a few hundred rows, and will likely mostly be in the buffer pool on all hosts, so most likely not the worst possible situation). Is there perhaps a mechanism to get mariadb to "break down" the searched for id value to enable it hitting the underlying indexes more properly? If not this is going to be a "let's see how far it stretches" kind of scenario for the time being, or possibly see if the mariadb query cache can help. In which case, is it possible to selectively enable the query cache on a per query basis, because as a rule we found that the query cache actually degraded performance (I believe due to lock contention). The only other option I can imagine is to create a separate table that regenerates whenever data in the source tables changes (by way of triggers). Kind regards, Jaco

3 5

Using mariabackup for partial backups
by Gingko 05 May '25

05 May '25

Hello, I have a problem when I want to use MariaBackup for getting a partial tables backup of a given database (actually willing to import them in another database right after in the same system after the copy, but this part doesn't seem to be relevant in this problem). For doing this, I proceed the following way: Suppose I have a database named “mydatabase” with some tables named “mytable1”, “mytable2”, “mytable3”, “mytable4”, etc., that I want to backup in a Linux folder like “/tmp/mydatabase/backup/”. But I only want to backup tables named “mytable3”, “mytable4” and “mytable5”. So I create a file named, for example, “/tmp/mydatabase-table-list.txt”, containing: mydatabase.mytable3 mydatabase.mytable4 mydatabase.mytable5 … and I issue the following command in a Linux bash shell, as told in the MariaBackup's documentation: mariabackup -u root --backup --target-dir=/tmp/mydatabase/backup/ --databases=mydatabase --tables-file=/tmp/mydatabase-table-list.txt At first, this seems to work, but actually, if I read the backup directory's contents after the backup, I see that _the whole database has been exported_, apparently _completely ignoring_ the “/tmp/mydatabase-table-list.txt” file's contents. But I can verify that this file is nevertheless read: If I put only this in the “/tmp/mydatabase-table-list.txt” file: mytable3 mytable4 mytable5 … I get an error message saying that the table names in the list must be qualified with database names (expected to be the same as in the --databases parameter, I suppose). Of course this doesn't work, but at least, this proves that the table list file is actually read. I also tried some other ways to specify the options, like removing the --databases=mydatabase parameter, but in this case I get no database contents, only the surrounding common files … … or writing the command like this, as the documentation seemed to allow it: mariabackup -u root --backup --target-dir=/tmp/mydatabase/backup/ --databases="mydatabase.mytable3 mydatabase.mytable4 mydatabase.mytable5" … with same result as above: no database contents. (by the way, my actual table names are not consistent between them like above, so I can't use any regex or wildcard parameter) My actual database is huge (more than 70 GB of files footprints), so it is really annoying to have to backup it as a whole. The database's size doesn't seem to be relevant: I also tested this with a smaller one with same results. What am I doing wrong in my “mariabackup” parameters? For information, the version that I use is “mariabackup based on MariaDB server 10.11.11-MariaDB debian-linux-gnu (x86_64)” (this is the result of the “mariabackup -v” command), and this is the one currently distributed as Debian packages with the “Debian GNU/Linux 12 (bookworm)” that I maintain in several servers and Linux boxes, matching the corresponding client and server versions installed on these systems. Gingko

1 0

MariaDB Bremen Meetup Tomorrow (Hybrid Event - Zoom Available)
by Anna Widenius 05 May '25

05 May '25

Dear MariaDB Community, Just a quick reminder that our next MariaDB Bremen Meetup is happening tomorrow, May 6! 📍 Location: Campus Ring 1, 28759 Bremen, Germany <https://maps.app.goo.gl/yTsBipcY5dyvLR3F6> (in person) 💻 Also available via Zoom (hybrid format) - https://constructor-university.zoom-x.de/j/68398052328 🕒 Time: 12:00 - 17:30 CEST 🔗 Event details and RSVP: https://www.meetup.com/mariadb-bremen-meetup-group/events/307250937/?eventO… Schedule: https://mariadb.org/events/code-vectors-and-vision/#schedule Whether you're joining us in person or online, we look forward to great discussios and networking around MariaDB and open source database technologies. Hope to see you there! best regards, Anna Widenius, CEO MariaDB Foundation |@mariadb_org | +358-45-2617358

1 0

Re: Fixing typos
by Lakhin Vasilii 29 Apr '25

29 Apr '25

Forgot to attach the patch I mentioned.

5 11

Which Mroonga version is being used?
by mariadb.robin842＠passfwd.com 29 Apr '25

29 Apr '25

Is there any way to check which Mroonga version is installed/being used? The GitHub repo shows commits from a few weeks ago in storage/mroonga, but running SELECT * FROM information_schema.PLUGINS; lists 7.7 as PLUGIN_VERSION, 1.15 as PLUGIN_LIBRARY_VERSION and 7.07 AS PLUGIN_AUTH_VERSION. So, which is it? Surely its not Mroonga 7.07 from 2017...

2 1

MariaDB 11.8 and Debian status - information to fellow Linux distro packagers/maintainers
by Otto Kekäläinen 28 Apr '25

28 Apr '25

Hi! Do we have any Linux distro packagers and maintainers on this mailing list? If you are working on importing MariaDB 11.8 into a Linux distro, you may want to take a peek at what was done in Debian, as it may save you some work in debugging build or test issues: * https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/latest * https://salsa.debian.org/mariadb-team/galera-4/-/commits/debian/latest You might also benefit from looking at work-in-progress and open Merge Requests at : * https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests In particular the MR https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/115 about a NEWS item to Debian users is likely to have useful text/summary that others might want to re-use: * https://salsa.debian.org/otto/mariadb-server/-/blob/dev/NEWS-11.8.2/debian/… Overall Debian package statuses are best viewed at: * https://tracker.debian.org/pkg/mariadb * https://tracker.debian.org/pkg/galera-4 ..and respective in Ubuntu: * https://launchpad.net/ubuntu/+source/mariadb * https://launchpad.net/ubuntu/+source/galera-4 I've fixed a lot of bugs in past weeks. The Debian tracker MariaDB bugs are down from 60 to 44, and in Ubuntu down to 3. For Galera the numbers are now down to 1 and 0. Looking forward to collaborate with maintainers of MariaDB and Galera packages in other Linux distributions! - Otto

1 0

INSERT INTO InnoDB hang without deadlock on 10.11.11
by Robert L Mathews 24 Apr '25

24 Apr '25

We run several MariaDB 10.11.11 servers, using the stock Debian 12.10 package (version 1:10.11.11-0+deb12u1). Very occasionally (perhaps once per four months of uptime per server) we see a situation where an InnoDB thread "hangs" in the "Update" state of a simple "INSERT INTO". When this happens, the only way to kill the thread is to "kill -9" the overall process (the thread doesn't respond to a normal "KILL HARD query_id", other than changing the state to "Killed"). It doesn't seem to be a deadlock. This problem is not limited to a single database or hardware server; I've seen it on several different databases and physical servers. I've captured a SHOW FULL PROCESS LIST and SHOW ENGINE INNODB STATUS of it happening, pasted both below and at <https://pastebin.com/gX6Hdxvx>. Is this a known issue? Any suggestions? Thanks! ------------------------------------------------------------------------ Id User Host db Command Time State Info Progress 8597007 redacted localhost redacted Query 72 Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('15', '2025-04-24 07:49:23', 1, '', '') 0.000 8597220 redacted localhost redacted Query 42 Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('15', '2025-04-24 07:49:52', 1, '', '') 0.000 8597326 redacted localhost redacted Query 32 Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('02', '2025-04-24 07:50:03', 1, '', '') 0.000 8597439 redacted localhost redacted Sleep 1 NULL 0.000 8597458 redacted localhost redacted Query 16 Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('<redacted>', '2025-04-24 07:50:18', 1, '', '') 0.000 8597682 redacted localhost redacted Query 2 Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('02', '2025-04-24 07:50:32', 1, '', '') 0.000 8597699 redacted localhost redacted Sleep 0 NULL 0.000 8597706 root localhost NULL Query 0 starting SHOW FULL PROCESSLIST 0.000 ===================================== 2025-04-23 23:50:35 0x7fbb111f66c0 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 30 seconds ----------------- BACKGROUND THREAD ----------------- srv_master_thread loops: 835 srv_active, 0 srv_shutdown, 798067 srv_idle srv_master_thread log flush and writes: 798902 ---------- SEMAPHORES ---------- ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2025-04-22 22:47:02 0x7fbb9c06c6c0 *** (1) TRANSACTION: TRANSACTION 15896049065, ACTIVE 0 sec fetching rows mysql tables in use 3, locked 3 LOCK WAIT 213 lock struct(s), heap size 24696, 18312 row lock(s) MariaDB thread id 7561112, OS thread handle 140443753301696, query id 1249654721 localhost redacted init for update UPDATE wp_actionscheduler_actions SET claim_id=3709294, last_attempt_gmt='2025-04-23 05:47:02', last_attempt_local='2025-04-23 06:47:02' WHERE claim_id = 0 AND scheduled_date_gmt <= '2025-04-23 05:47:02' AND status='pending' ORDER BY priority ASC, attempts ASC, scheduled_date_gmt ASC, action_id ASC LIMIT 25 *** WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 1369764 page no 991 n bits 768 index status of table `redacted`.`wp_actionscheduler_actions` trx id 15896049065 lock_mode X waiting Record lock, heap no 671 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b9bb78; asc x;; *** CONFLICTING WITH: RECORD LOCKS space id 1369764 page no 991 n bits 768 index status of table `redacted`.`wp_actionscheduler_actions` trx id 15896049073 lock_mode X locks rec but not gap Record lock, heap no 671 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b9bb78; asc x;; 98 *** CONFLICTING WITH: RECORD LOCKS space id 1369764 page no 991 n bits 768 index status of table `redacted`.`wp_actionscheduler_actions` trx id 15896049065 lock_mode X Record lock, heap no 662 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b800cf; asc ;; Record lock, heap no 663 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b8044b; asc K;; Record lock, heap no 664 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b84042; asc @B;; Record lock, heap no 665 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b95118; asc Q ;; Record lock, heap no 666 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b9909f; asc ;; Record lock, heap no 667 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b99a64; asc d;; Record lock, heap no 668 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 7; hex 70656e64696e67; asc pending;; 1: len 8; hex 0000000000b99a65; asc e;; *** WE ROLL BACK TRANSACTION (1) ------------ TRANSACTIONS ------------ Trx id counter 15900136305 Purge done for trx's n:o < 15900136296 undo n:o < 0 state: running History list length 1407 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION (0x7fbb9f404380), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION (0x7fbb9f406f80), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION (0x7fbb9f3ff680), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION (0x7fbb9f404e80), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION (0x7fbb9f405980), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION 15900136247, ACTIVE 3 sec inserting mysql tables in use 1, locked 1 1 lock struct(s), heap size 1128, 0 row lock(s) MariaDB thread id 8597682, OS thread handle 140443754120896, query id 1424570532 localhost redacted Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('02', '2025-04-24 07:50:32', 1, '', '') ---TRANSACTION (0x7fbb9f402d80), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION (0x7fbb9f400c80), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION 15900135437, ACTIVE 17 sec inserting mysql tables in use 1, locked 1 1 lock struct(s), heap size 1128, 0 row lock(s) MariaDB thread id 8597458, OS thread handle 140444290127552, query id 1424555212 localhost redacted Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('<redacted>', '2025-04-24 07:50:18', 1, '', '') ---TRANSACTION (0x7fbb9f407a80), not started 0 lock struct(s), heap size 1128, 0 row lock(s) ---TRANSACTION 15900134864, ACTIVE 32 sec inserting mysql tables in use 1, locked 1 1 lock struct(s), heap size 1128, 0 row lock(s) MariaDB thread id 8597326, OS thread handle 140443754325696, query id 1424540084 localhost redacted Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('02', '2025-04-24 07:50:03', 1, '', '') ---TRANSACTION 15900134271, ACTIVE 43 sec inserting mysql tables in use 1, locked 1 1 lock struct(s), heap size 1128, 0 row lock(s) MariaDB thread id 8597220, OS thread handle 140441414899392, query id 1424530951 localhost redacted Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('15', '2025-04-24 07:49:52', 1, '', '') ---TRANSACTION 15900132917, ACTIVE 72 sec inserting mysql tables in use 1, locked 1 1 lock struct(s), heap size 1128, 0 row lock(s) MariaDB thread id 8597007, OS thread handle 140441423496896, query id 1424510658 localhost redacted Update INSERT INTO `wp_rank_math_404_logs` (`uri`, `accessed`, `times_accessed`, `referer`, `user_agent`) VALUES ('15', '2025-04-24 07:49:23', 1, '', '') ---TRANSACTION (0x7fbb9f3feb80), not started 0 lock struct(s), heap size 1128, 0 row lock(s) -------- FILE I/O -------- Pending flushes (fsync): 0 166351415 OS file reads, 6987933 OS file writes, 3639237 OS fsyncs 156.66 reads/s, 7878 avg bytes/read, 71.50 writes/s, 13.17 fsyncs/s ------------- INSERT BUFFER ------------- size 6, free list len 11863, seg size 11870, 0 merges merged operations: insert 0, delete mark 0, delete 0 discarded operations: insert 0, delete mark 0, delete 0 --- LOG --- Log sequence number 17970676587722 Log flushed up to 17970676583883 Pages flushed up to 17970643193368 Last checkpoint at 17970643193368 ---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 2181038080 Dictionary memory allocated 92637472 Buffer pool size 129791 Free buffers 1396 Database pages 128387 Old database pages 47412 Modified db pages 80 Percent of dirty pages(LRU & free pages): 0.062 Max dirty pages percent: 90.000 Pending reads 0 Pending writes: LRU 0, flush list 15 Pages made young 196468759, not young 3200160866 65.33 youngs/s, 3222.73 non-youngs/s Pages read 166314664, created 2924018, written 6791751 156.66 reads/s, 3.00 creates/s, 70.53 writes/s Buffer pool hit rate 994 / 1000, young-making rate 2 / 1000 not 108 / 1000 Pages read ahead 81.03/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 128387, unzip_LRU len: 0 I/O sum[10256]:cur[2292], unzip sum[0]:cur[0] -------------- ROW OPERATIONS -------------- 1 read views open inside InnoDB state: sleeping ---------------------------- END OF INNODB MONITOR OUTPUT ============================ -- Robert L Mathews

1 0

Client version >= 11.4.1 can't connecto MariaDB server 11.4.5
by gerhard.pauls＠eviden.com 15 Apr '25

15 Apr '25

Hi, I installed MariaDB 11.4.5 on Windows Server 2019. The command line client installed together with server can't connect: C: \Program Files\MariaDB 11.4\bin>mysql -u user -p ERROR 2813 (HY000): Lost connection to server at 'sending authentication information', system error: 0 In the server err log: [Warning] Could not read packet: fd: 1424 state: 1 read length: 4 errno: 0 vio_errno: 1158 length: -1 Problem does not occur with HeidiSQL. Problem does not occur with MariaDB clients version 11.4.0 or lower Problem occurs with MariaDB clients version 11.4.1 or higher Any idea what the problem might be? Best regards, Gerhard

3 2

Busy_time rate is a million times higher from 11.4.4 to 11.4.5
by mdbml.myself854＠passmail.net 14 Apr '25

14 Apr '25

Good day When I start a 11.4.4 image and I watch USER_STATISTICS.BUSY_TIME refreshing it every second or so, it increases with about 0.0002 at a time (for a user that's not really doing anything). But when I do the same in a 11.4.5 image it goes up by about 200 at a time (while the user is still not doing anything). I think that's wrong because it's supposed to be "number of seconds of activity". I couldn't find anything about it in the release notes https://mariadb.com/kb/en/mariadb-11-4-5-release-notes/ . Any ideas? I also see this in production and it quite messes up our metrics 😅 Thanks you

3 3

How to add a second Maxscale node
by Richard Reina 14 Apr '25

14 Apr '25

I have configured a second Maxscale node and was hoping to use it as a backup in case my other Maxscale node should fail. My question is how do I deploy it? I take it starting it up and having two Maxscale nodes working at the same time would be a problem because the both might try to effectuate failover changes such as promotions simultaneously that could cause conflicts? I have written the perl code below that can randomly select a node, but it would need two working nodes to choose between. How does one deploy a second node without it conflicting with the first Maxscale node? my @msn = qw(192.168.0.24 192.168.0.23); # Maxscale Nodes my $msn = $msn[rand @msn]; my $msn = splice(@msn, rand @msn, 1); print "I picked: $msn\n"; print "Remaining Maxscale Nodes are: @msn\n"; $dbh = DBI->connect("DBI:mysql:database=$self->{_db_name};host=$msn;port=4006",$user, $pwd);

2 1

increasing InnoDB history length and stalls on MariaDB 11.4
by kazuhiko＠nexedi.com 10 Apr '25

10 Apr '25

Hello, Our application has a sustained rate of DML queries in parallel with DQL. We can achieve good performance using innodb-locks-unsafe-for-binlog on MariaDB 10.4, with careful consideration of its 'unsafeness'. But innodb-locks-unsafe-for-binlog is removed in MariaDB 10.5 or later and our application runs much slower without it because of gap locking. https://mariadb.com/docs/server/ref/mdb/cli/mariadbd/innodb-locks-unsafe-fo… To achieve a good performance as before, we now use READ COMMITTED transaction isolation for DML and use REPEATABLE READ isolation for DQL on MariaDB 11.4. This way guarantees the consistency for our application. Our database contains totally 13.7G rows and uses 4.5TB storage. Here is the configuration : innodb_buffer_pool_size = 17179869184 (16GB) innodb_buffer_pool_instances = 16 (no meaning in 11.4) innodb_log_file_size = 134217728 (128MB) innodb_flush_method = O_DIRECT Please see the attached graphs drawing 'InnoDB history length (right axis)' and 'free redo log in % (left axis)' (i.e. 100 - Redo Log Occupancy) while running our reference workload. https://mariadb.com/kb/en/innodb-redo-log/#determining-the-redo-log-occupan… These tests are done with the same workload, but only MariaDB version and/or configuration is different. (Please disregard the 'warehouse history length' and 'activities history length' series in those plots, they are not relevant to the current issue.) On MariaDB 10.4, the performance and the behaviour between 'using innodb-locks-unsafe-for-binlog' and 'using READ COMMITTED and REPEATABLE READ' are similar. But on MariaDB 11.4, I found two serious issues. Issue 1: InnoDB history length keeps growing while running lots of DML and DQL queries in parallel. InnoDB history length is stable around 5k on 10.4, but it keeps growing on 11.4 up to 100k until the end. In our experience, increases in history list length are roughly correlated with poor query performance (causing queries to "step over tombstones" ?), and we do our best to avoid having long-running transactions in order to allow older snapshots to be freed ASAP. We are satisfied with the status on 10.4, where history list is constant. What is the reason behind such increases on 11.4 and is there any configuration to avoid such ? Issue 2: MariaDB stalls when free redo log is too small. When MariaDB stalls, even a quite simple query takes too long. (table definition) CREATE TABLE `catalog` ( `uid` bigint(20) unsigned NOT NULL, `path` varchar(255) NOT NULL DEFAULT '', ... PRIMARY KEY (`uid`), KEY `Path` (`path`), ... ) (from pt-query-digest output) # Attribute pct total min max avg 95% stddev median # ============ === ======= ======= ======= ======= ======= ======= ======= # Count 2 91 # Exec time 2 716s 1s 17s 8s 15s 5s 7s # Lock time 0 22ms 156us 491us 238us 366us 70us 204us # Rows sent 0 663 3 10 7.29 8.91 1.09 6.98 # Rows examine 0 663 3 10 7.29 8.91 1.09 6.98 # Rows affecte 0 0 0 0 0 0 0 0 # Bytes sent 0 52.10k 330 749 586.24 685.39 68.46 563.87 # Query size 0 470.83k 3.56k 5.26k 5.17k 5.20k 225.56 5.20k SELECT uid, path FROM catalog WHERE path in ('...', /*... omitted 80 items ...*/)\G (here, these SELECT are issued in READ COMMITTED isolation level) Our understanding is that the stalls are caused by the undo log cleanup job, and/or the innodb buffer pool writeback job. Increasing the undo log size a lot seems to reduce the frequency of those stalls. For our reference workload here, we still have stalls with 1GB log file but we don't have stalls with 2GB or more log file. If we need 'big enough' log file size to avoid stalls, will the ideal size be proportional to the amount of data or proportional to the buffer pool size ? We have never had such stall on MariaDB 10.4 even with small 128MB log file. How this difference happen and is there any configuration to improve the behaviour ? Thanks in advance ! Best regards, Kazuhiko SHIOZAKI

4 17

Ansible role to deploy madiadb gaelra cluster using containers
by Engelmann Florian 08 Apr '25

08 Apr '25

Hi, is there any production ready ansible role to deploy a mariadb galera cluster using docker container (not packages)? All the best Florian EveryWare AG Florian Engelmann Cloud Platform Architect Zurlindenstrasse 52a CH-8003 Zürich T +41 44 466 60 00 F +41 44 466 60 10 florian.engelmann(a)everyware.ch www.everyware.ch

2 1

Moving forward the pull request
by pslawek83 08 Apr '25

08 Apr '25

Hello Everyone, made some changes to my pull request. How to move it forward? Want to see if design is ok to make some final code changes. github.com https://github.com/MariaDB/server/pull/3891 Thanks

1 0

presenting binary data as hex strings by default
by Jaco Kroon 07 Apr '25

07 Apr '25

Hi All, This would be a mis-feature probably, but please bear with me. Getting binary data dumped to a terminal is not fun. Is there perhaps a way to set it such that *binary types would be displayed/presented as hex string rather than raw binary? In particular when using CLI tools? I'm aware of the HEX() function which achieves same, but you need to do that for every column, when inspecting data and just starting off with something like "select * from" ... I suspect having a flag to inform the cli client tools to present such binary columns as hexadecimal strings instead of dumping raw binary data to the terminal would be most helpful. Sorry, just had a round of screeching in my ears from "bell" characters and was just wondering if there's a way to not only stop that, but present the data in a more sensible manner regardless, ideally some "opt in" mechanism to maintain backwards compatibility. Kind regards, Jaco

2 1

Adding an index to a large table
by edi mari 04 Apr '25

04 Apr '25

Hi, I have a 200GB table with a foreign key constraint, and I need to drop an existing index and add a non-unique index to it. What is the best approach to do this with minimal impact on users? Thanks Edi

6 12

it is normal to have a memory usage of 85%?
by cata 04 Apr '25

04 Apr '25

Hi everybody, I am new here and I am confronted with a situation, so I will start with the questions first: 1. It is normal that on my server, mariadb to use almost 85% of available ram or something is wrong? 2. In case I want to limit the whole application (mariadb) to not use more than 5.5 GB RAM from total of 7.8GB it could be possible - without affecting it's performance? 3. Is anything to optimize (change) now? If yes, which variable? 4. Do we need more RAM for this server or actual RAM could be enough? See below: Operating system: "Debian 12.10 (bookworm)" MariaDB Version: 10.11.11-MariaDB-0+deb12u1-log The server was configured (limited) to use for InnoDB -> max 3GB Ram MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size'; +-------------------------+------------+ | Variable_name | Value | +-------------------------+------------+ | innodb_buffer_pool_size | 3221225472 | +-------------------------+------------+ 1 row in set (0.001 sec) But, on that server *we are running also MySam, Memory *and Innodb, in total, ~70 databases (8 MySam, 1 MEMORY, and the rest are InnoDB) MariaDB [mysql]> select count(distinct db) from db; +--------------------+ | count(distinct db) | +--------------------+ | 73 | +--------------------+ 1 row in set (0.001 sec) MariaDB [mysql]> SYSTEM 4CPU, 7.8GB RAM root@adsns-db-node0:~# df -h Filesystem Size Used Avail Use% Mounted on udev 3.8G 0 3.8G 0% /dev tmpfs 776M 764K 775M 1% /run /dev/sda1 150G 48G 97G 34% / tmpfs 3.8G 0 3.8G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/sda15 241M 138K 241M 1% /boot/efi tmpfs 776M 0 776M 0% /run/user/0 root@adsns-db-node0:~# I found some articles on internet regarding /dev/shm, which could influence mysql performance. In my case /dev/shm is not used even defined, so the system could use the whole available RAM - 7.8GB RAM, so I excluded this as possible cause. MariaDB [(none)]> SHOW VARIABLES LIKE '%buffer_size%'; +----------------------------+-----------+ | Variable_name | Value | +----------------------------+-----------+ | aria_pagecache_buffer_size | 134217728 | | aria_sort_buffer_size | 268434432 | | bulk_insert_buffer_size | 8388608 | | innodb_log_buffer_size | 16777216 | | innodb_sort_buffer_size | 1048576 | | join_buffer_size | 4194304 | | key_buffer_size | 10485760 | | mrr_buffer_size | 262144 | | myisam_sort_buffer_size | 134216704 | | preload_buffer_size | 32768 | | read_buffer_size | 131072 | | read_rnd_buffer_size | 262144 | | sort_buffer_size | 2097152 | +----------------------------+-----------+ 13 rows in set (0.001 sec) Traffic is not high, just 123 queries per second. MariaDB [(none)]> status; -------------- mysql Ver 15.1 Distrib 10.11.11-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper Connection id: 877596 Current database: Current user: root@localhost SSL: Not in use Current pager: stdout Using outfile: '' Using delimiter: ; Server: MariaDB Server version: 10.11.11-MariaDB-0+deb12u1-log Debian 12 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: utf8mb4 Db characterset: utf8mb4 Client characterset: utf8mb3 Conn. characterset: utf8mb3 UNIX socket: /run/mysqld/mysqld.sock Uptime: 7 days 3 hours 24 min 6 sec Threads: 78 Questions: 75901186 Slow queries: 4891595 Opens: 12573592 Open tables: 2000 Queries per second avg: 123.007 -------------- MariaDB [(none)]> Even I am restarting mariadb, after a short time, the memory usage is 85% root@adsns-db-node0:~# free -g total used free shared buff/cache available Mem: 7 6 0 0 0 1 Swap: 0 0 0 root@adsns-db-node0:~# The swap is not used, just the memory, which is ok. CPU usage is less than ~10%, so is ok. See below, output of top. %Cpu(s): 2.2 us, 0.7 sy, 0.0 ni, 96.2 id, 0.4 wa, 0.0 hi, 0.4 si, 0.0 st MiB Mem : 7750.8 total, 161.4 free, 6351.8 used, 712.6 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1399.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1555028 mysql 20 0 7752424 6.5g 15476 S 10.6 85.2 188:29.16 mariadbd root@adsns-db-node0:~# pstree |grep maria |-mariadbd---51*[{mariadbd}] root@adsns-db-node0:~# All 51 childs of mariadb are using 85% from the system memory (each child ~1.6% of total RAM). I found a mysql calculator and changing innodb_buffer_pool_size - its default value 8M - with 3G, I got ~3.7GB ... still not 6.6G (aprox 85% from total RAM). See: https://www.mysqlcalculator.com/ 5. Why this difference, from 3.7GB up to 6.6GB? 6. Where could it be the rest of 2GB which is used by mariadb (from 3.7GB up to 6.6GB)? Any help will be appreciated. Catal

4 5

InnoDB buffer pool usage drops regularly since 10.11.10 / 11.4.4
by William David Edwards 02 Apr '25

02 Apr '25

Hi, We see an odd pattern where InnoDB buffer pool usage drops regularly. Attached are two screenshots of memory usage on an 11.4.4 node: one at 20:15 with an InnoDB buffer pool of 47,5 GiB, and 5 minutes later with a 3,69 GiB one. The times at which this occurs are -seemingly- random. Other internal memory structures are stable. On at least one node with this issue, the InnoDB buffer pool is smaller (48 GiB) than the sum of data + indexes (87,57 GiB). As far as I can see (graphing history is limited), this has started occurring after upgrading from MariaDB 10.11.9 to 10.11.10 and from 11.4.3 to 11.4.4 respectively. At first sight, in the pre-release notes for 10.11.11 and 11.4.5, I don't see any related issues. To make absolutely sure this is related to the upgrade, we will be downgrading a troubled node tonight, to see if it fixes anything. I will report back. In userland, these drops cause a domino effect: no cache -> more I/O -> slower queries -> nuisance in application. Has anyone else seen this pattern, possibly after upgrading to the aforementioned versions? Although 1) neither of these versions are bleeding edge and 2) I haven't seen any such reports, asking is worth a shot as this started occurring on several machines after upgrading with no configuration nor (obvious) usage changes. With kind regards, William David Edwards

3 4

active-backup or active-active solution in docker swarm
by vbvbrj 01 Apr '25

01 Apr '25

Hello. Did anyone managed to create a master-backup or master-master deployment of mariadb in docker swarm to work consistent and stable? Community, please help me with a yaml config in docker swarm to deploy a master-active or better master-master config of mariadb which will handle servers restart on full stack shutdown and restart without any implications. Can someone who did this share theirs yaml config for docker swarm? I tried the examples on percona page and as data was populated the synconizations of services were lost. Thank you.

1 0

is blocked because of many connection
by Marc 31 Mar '25

31 Mar '25

I am constantly getting abuse from azure, amazon, digital ocean cloud. With previous mysql versions I never got this message. I assume you have set this to a default. I don't want to have this limit on ip but on ip+database, how can I change this?

6 40

Re: Troubleshooting major performance issue.
by pslawek83 30 Mar '25

30 Mar '25

1 0

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

This month in the MariaDB Foundation
by Anna Widenius 21 Feb '25

21 Feb '25

"Focus, focus, focus! That’s the mantra of any successful organisation. With great input from our Board, we’ve managed to condense our strategic planning for 2025 into six goals." Read Kaj Arnö’s blog about the MariaDB Foundation’s goals for 2025 - https://mariadb.org/this-month-2025-jan/ Anna Widenius Chief of Staff, MariaDB Foundation

1 0

Vector indexing questions for deep-image-96-angular dataset
by shiyer22＠gmail.com 19 Feb '25

19 Feb '25

Greetings! I am doing some benchmarking on MariaDB and got to the deep-image-96-angular dataset from https://github.com/erikbern/ann-benchmarks. This dataset has 9.99 million vectors of dimension 96. I am running the vector index create with M=24,ef_construction = 200 (similar parameters as pgvector in ANN-Benchmark). I wanted to check and confirm a couple of observations based on the progress of the index create at present - MariaDB [(none)]> show processlist; +----+--------+-----------+------+---------+------+-------------------+----------------------------------------------------------+----------+ | Id | User | Host | db | Command | Time | State | Info | Progress | +----+--------+-----------+------+---------+------+-------------------+----------------------------------------------------------+----------+ | 4 | ubuntu | localhost | ann | Query | 4092 | copy to tmp table | ALTER TABLE t1 ADD VECTOR INDEX (v) M=24 DISTANCE=cosine | 9.636 | MariaDB [(none)]> select trx_rows_modified from information_schema.innodb_trx; +-------------------+ | trx_rows_modified | +-------------------+ | 125215100 | +-------------------+ 1 row in set (0.004 sec) -rw-rw---- 1 ubuntu ubuntu 40420507648 Feb 19 06:20 undo002 Can you please confirm that the undo log reaching 40GB+ is expected for a progress of 9%? Did I miss something? I have configured the hnsw cache size and buffer pool to 16GB each. Should I increase them further? I want to benchmark for "hnsw index fits in memory" use-case. MariaDB [(none)]> show variables like '%hnsw%'; +------------------------+-------------+ | Variable_name | Value | +------------------------+-------------+ | mhnsw_default_distance | euclidean | | mhnsw_default_m | 24 | | mhnsw_ef_search | 200 | | mhnsw_max_cache_size | 17179869184 | +------------------------+-------------+ 4 rows in set (0.001 sec) Just to let know, I am working on the vector plugin for MySQL (MyVector) Thanks!

3 4

Fixing typos
by qobood＠gmail.com 15 Feb '25

15 Feb '25

Greetings! I've made a simple patch with some corrected typos, is there an interest for this initiative? If so, I can continue doing this thing, requesting approval for this patch and next ones.

1 0

Rebuild repodata for EL7 repo
by Software Mirror Team 05 Feb '25

05 Feb '25

Hi, Would it be possible to rebuild repodata for https://mirror.mariadb.org/yum/10.11/rhel/7/x86_64/? We are using Foreman (https://theforeman.org/) to mirror different software in our network. All other MariaDB repos are fine, but for 10.11/rhel/7 we are getting "404, message='Not Found', url=URL('https://mirror.mariadb.org/yum/10.11/rhel/7/x86_64/srpms/MariaDB-10.11.7-1.…')" It looks like the repodata still contains references to removed files. Our apologies if this list is not appropriate. Thank you in advance. Best regards, IIS Mirror team

2 2

Are the mariadb repos working?
by Simon Avery 04 Feb '25

04 Feb '25

Hi Struggling to install mariadb-server 11.10 onto a new Rocky9 vm today. I've previously used a saved repo which has baseurl=https://dlm.mariadb.com/repo/mariadb-server/10.11/yum/rhel/9/x86_64 But that's returning 404 in most of the tree. I followed some other instructions from https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/ Which downloaded mariadb_repo_setup which, when run, created a .repo file with baseurl https://dlm.mariadb.com/repo/mariadb-server/11.rolling/yum/rhel/9/x86_64 That url is also returning 404 for me, all the way up the tree to the domain. Is it you guys, or is it me? Thanks, Simon Avery Linux Sysadmin: ATASS Sports Oxygen House | Grenadier Road, Exeter Business Park | EX1 3LH t: 01392 440 400 e: simon.avery(a)atass-sports.co.uk<mailto:simon.avery@atass-sports.co.uk> www.atass-sports.co.uk<http://www.atass-sports.co.uk/> Follow us on X: @atassSports<https://twitter.com/atassSports> NOTICE This email and any attachments confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Please notify the sender immediately. ATASS Ltd is incorporated in England and Wales with company number 04807405. See our website for further details and our privacy policy

3 3

Are default_m and ef_search "implementation specific" vector store parameters?
by Vishal Rao 30 Jan '25

30 Jan '25

Hello, I'm replacing the use of Chroma with MariaDB as the vector store and the Chroma code sets the ef_search parameter to a value of 50. My question is, to achieve "similar results" with the MariaDB vector store will setting ef_search to 50 here as well have the intended effect? Or is there no relation between the actual values across implementations and I need to experiment/test to observe how MariaDB performs to arrive at an appropriate value for it? Thank you. -- "The World is a book, and those who do not travel read only a page." - St. Augustine.

2 2

Set vector ef_search value in CREATE TABLE statement?
by Vishal Rao 30 Jan '25

30 Jan '25

Hello! The mariadb vector 11.7.1-rc release has the option to specify default_m in the CREATE TABLE statement VECTOR specification by including "M=x" option but apparently no option to specify the ef_search value. Is there any intent to add this option to the CREATE TABLE statement on the roadmap - I hope this is a valid way to set the ef_search value per table? Currently I saw this comment here : https://jira.mariadb.org/browse/MDEV-35244?focusedCommentId=293664&page=com… which I can use as a workaround to set session value of ef_search for my needs but wanted to know if I can open a Jira wishlist ticket unless this is already planned? Thanks! -- "The World is a book, and those who do not travel read only a page." - St. Augustine.

3 4

Incorrect CN Being Reported When Using Postfix With MariaDB
by duluxoz 24 Jan '25

24 Jan '25

Hi All, I'm not sure if this is was Postfix issue, a TLS Certificate issue, and/or a MariaDB issue, so I started in the Postfix mailing lists. Their reply (below) indicated that I should post here instead - apologises if this is not the right place. My original post: I'm using a MariaDB backend to Postfix. Everything is working correctly until I attempt to secure the Postfix<->MariaDB connection with a TLS Certificate. When I perform a `postmap -q example.com mysql:/etc/postfix/virtual_domains.cf` command on the postfix server *without* using TLS I get a successful response. However, when I engage TLS I get the following error in the MariaDB log: `X509 subject mismatch: should be 'CN=mail_user(a)example.com' but is '/CN=mail_user(a)example.com'`. Now, obviously the issue is the extra '/' at the start of the 'CN=', but for the life of me I can't figure out where that '/' is coming from. It is *not* in the TLS Certificate (verified by OpenSSL). It is *not* in the virtual_domains.cf file (see below). It is *not* in the MariaDB 'GRANT' statement used to allow access to the database: `GRANT SELECT ON mail_server.* TO 'mail_user'@'example.com' IDENTIFIED BY '{PASWORD OBSCURED}' REQUIRE SUBJECT 'CN=mail_user(a)example.com'`. OS of both servers: Rocky Linux 9.5 Postfix Version: 3.9.1 MariaDB Version: 11.6.2 virtual_domains.cf: ~~~ hosts = mariadb.example.com dbname = mail_server user = mail_user password = {PASWORD OBSCURED} tls_cert_file = /etc/pki/tls/certs/mail_user(a)exampl.com.crt tls_key_file = /etc/pki/tls/certs/mail_user(a)exampl.com.key tls_CApath = /etc/pki/tls/certs/root_ca.crt query = SELECT TRUE FROM virtual_domains WHERE domain_name='%s' ~~~ The Postfix mailing List Reply: There is (of course if happens to know too much about X.509 naming) no such "slash" in the actual certificate. The subject DN is a sequence of relative distinguished names (RDNs) of which CN=... is in this case the first element. There are many ways to write the sequence as a string, the two most popular are: /RDN1/RDN2/.../RDNx RDN1, RDN2, ..., RNDx It looks you have a buggy MariaDB library that expects to get DNs in the second format, but ends up with the first, because of a failure to be specific about the format, or just outright getting it wrong... Perhaps the default changed between OpenSSL 1.1.1 and 3.0, or something about the way OpenSSL was built? Anyway, Postfix is just the messenger, it is the MariaDB library that sets up TLS connection. Could someone please point me in the right direction to get this sorted - thanks Cheers Dulux-Oz

2 2

galera | mariabackup SST fails with Database page corruption detected
by sacawulu 21 Jan '25

21 Jan '25

Hi, Short outline: I am testing backup restores in a 3-node galera cluster used for zabbix from backups made with mariabackup. Everything is running virtualized under virtualbox/almalinux9, mariadb version 10.11 on XFS, wsrep_sst_method = mariabackup We have a FULL mariabackup from a few days ago and an INCREMENTAL backup from today, both including --galera-info. Steps taken: - made sure mariadb was shutdown on all nodes - extract and prepare the full backup - applied the incremental to the full - prepared again (which is not neccesary, I think..?) No errors, all finished as expected - set correct permissions, including selinux context - moved (manually) the result back into <datadir> on one node - bootstrapped galera_new_cluster this node This all worked, no errors. Then on one of the two remaining nodes: - emptied <datadir> - systemctl start mariadb This fails, with logging on the donor: > [01] 2025-01-17 11:59:24 Streaming ./acc_zabbix/valuemap.ibd > [01] 2025-01-17 11:59:24 ...done > [01] 2025-01-17 11:59:24 Streaming ./acc_zabbix/items.ibd > [01] 2025-01-17 11:59:24 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:24 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:24 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:24 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:24 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:24 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:25 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:25 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:25 Database page corruption detected at page 1532, retrying... > [01] 2025-01-17 11:59:25 Error: failed to read page after 10 retries. File ./acc_zabbix/items.ibd seems to be corrupted. > len 16384; hex 6a88faf1cd270aa737902c6aac0bc8ff4cfef39f4c2ee1fe9a957bac05ac642a78e50468b09ea5d65b58fea9a708ed5c22ec10b0ccf46c0e7f2bdf86d2667c22c1902483c0a34607baab109d01635f4687bf5fddc8f2d7b6723813825b630a8315675e78b4b8d0336a4ad66e867e878690e092286bc3ba8259dbb21475b45198d20dc33488b8a3e407a91557c0a77598bf6cd2a81da3388c8d629466ffdf258a3d3e837d9f4cb54a13847495b64d616b801cdd237c1af0f52b9ace7fbc37601a7b5da5264a5478d926c0e50554f811b6d2586288c2b7df74ce5a3b0e9f2f6546846ffe9890fb21b19e23703f1e243c9d67514bcee9685be15dea8afc6c018290731dc517c894394ff72e1a913b6a197d422dadaed06d968abc8e784f9347b2ffd79fcbdee20c7a566ab8374c7ed4fa78977cf0fc10ae402900676b5c3b6a427a26a987743ccdf3d93b32d3a4544c5ba9f4bfa50f910765e5349f605cad4c874061aa9f3339870ef745e7e40d1 So on the donor I ran: > mariadb-check --all-databases All OK, no errors. Then on the doner I ran > mysqldump --all-databases > /tmp/alldb.sql also works, and /tmp/alldb.sql looks healthy, ending with -- Dump completed on 2025-01-17 12:06:40 And then, just for fun, I tried to create a fresh mariabackup from this restored database on donor, and yes, it fails with the same error that items.ibd seems to be corrupted. Then I changed wsrep_sst_method to rsync, and attempted to start the other two nodes: the SST worked, nodes came online, DB/galera came up healthy: zabbix is now running. Just for fun I also tried making a mariaback on one of the other (now syned) galera nodes, and it fails also, but on a different table: > [01] 2025-01-17 12:34:48 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:34:48 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:34:48 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:34:48 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:34:48 Error: failed to read page after 10 retries. File ./acc_zabbix/auditlog.ibd seems to be corrupted. So I'm looking for feedback here: what is happening? IS my db corrupted, or NOT? How to better check? Why would mariadb-check, mysqldump, plus zabbix all work, but can I no longer run mariabackup. Is there something wrong/missing in the procedure outlined above? Are there better ways to check integrity? Luckily this is all testing, and I'm just trying to understand things better. :-) Ending with the complete output of mariabackup errors, as perhaps it means something to someone..? Thanks! MJ > [02] 2025-01-17 12:21:29 Streaming ./acc_zabbix/changelog.ibd > [01] 2025-01-17 12:21:29 Database page corruption detected at page 363, retrying... > [01] 2025-01-17 12:21:30 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:21:30 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:21:30 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:21:30 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:21:30 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:21:30 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:21:30 Database page corruption detected at page 363, retrying... > [02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > [01] 2025-01-17 12:21:30 Error: failed to read page after 10 retries. File ./acc_zabbix/auditlog.ibd seems to be corrupted. > len 16384; hex 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000[02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000616c2d76616375756d3a2072656e616d652066756e6374696f6e20746f206d6174636820737472756374206e616d6520282332313832363332290a2d206a6f75726e616c2d76616375756d3a2075736520434c45414e55505f415252415920282332313832363332290a2d2070616d3a206164642063616c6c20746f2070616d5f756d61736b20282332323130313435290a2d20756465762d6275696c74696e2d6e65745f69643a20616c69676e20564620726570726573656e746f72206e616d65732077697468205646206e616d657320282332323138383836290a2d2070616d3a2061646420612063616c6c20746f2070616d5f6e616d65737061636520282332323138313834290a2d2072756c65733a206f6e6c696e6520435055206175746f6d61746963616c6c79206f6e2049424d20733339307820706c6174666f726d73207768656e20636f6e6669677572656420282332323132363132290a2d20636f72652f6d6f756e743a2065736361706520696e76616c69642055544638206368617220696e2064627573207265706c7920282332323038323430290a2d205265766572742022757365723a2064656c65676174652063707520636f6e74726f6c6c65722c2061737369676e207765696768747320746f207573657220736c696365732220282332313736383939290a2d20756465762d72756c65733a20666978206e766d652073796d6c696e6b206372656174696f6e206f6e206e616d657370616365206368616e67657320282332313732353039290a2d2072756c65733a20616464207768697465737061636520616674657220636f6d6d61206265666f726520746865206c696e6520636f6e74696e756174696f6e20282332313732353039290a2d20756465763a20726573746f726520636f6d7061742073796d6c696e6b20666f72206e766d65206465766963657320282332313732353039290a2d2072756c65733a2064726f7020646f75626c656420737061636520282332313732353039290a2d206d616e616765723a20646f6e2774207461696e742074686520686f7374206966206367726f757073207631206973207573656420282332313933343536290a2d20636f72652f00003895000000002840c66b57bff3333e9bd34a3f62511e00003896736572766963653a207768656e20726573657474696e672050494420616c736f207265736574206b6e6f776e20666c616720282332323130323337290a2d2063693a2064726f702073797374656d642d737461626c652066726f6d20616476616e6365642d636f6d6d69742d6c696e74657220636f6e6669672028233231373038383329002d2063693a20747269676765722060646966666572656e7469616c2d7368656c6c636865636b6020776f726b666c6f77206f6e207075736820282332313030343430290a2d2063693a20776f726b666c6f7720666f7220676174686572696e67206d6574616461746120666f7220736f757263652d676974206175746f6d6174696f6e20282332313030343430290a2d2063693a2066697273742070617274206f662074686520736f757263652d676974206175746f6d6174696f6e202d20636f6d6d6974206c696e74657220282332313030343430290a2d206369284d657267696679293a20636865636b20436f6465514c20616e64206275696c6420776f726b666c6f7773206261736564206f6e206368616e6765642066696c657320282332313030343430290a2d2063693a20616464204e4f5449434520746f20616c736f207570646174652072656765787020696e20602e6d6572676966792e796d6c60207768656e207570646174696e6720607061746873602070726f706572747920282332313030343430290a2d20537570706f7274202f6574632f73797374656d2d75706461746520666f72204f53547265652073797374656d7320282332323033313333290a2d206a6f75726e616c2d6465663a206669782074797065206f66207369676e617475726520746f206d61746368207468652061637475616c206669656c6420696e20746865204865616465722073747275637475726520282332313833353436290a2d206a6f75726e616c3a2075736520636f6d706f756e6420696e697469616c697a6174696f6e20666f72206a6f75726e616c2066696c65204865616465722073747275637475726520282332313833353436290a2d206a6f75726e616c643a20666978206c6f67206d65737361676520282332313833353436290a2d2073642d6a6f75726e616c3a20636163686520726573756c7473206f662070617273696e6720656e7669726f6e6d656e74207661726961626c657320282332313833353436290a2d20636f6d70726573733a20696e74726f6475636520636f6d7072657373696f6e5f737570706f7274656428292068656c7065722066756e6374696f6e20282332313833353436290a2d2073642d6a6f75726e616c3a20616c77617973207573652074686520636f6d7072657373696f6e20616c676f726974686d2073706563696669656420696e207468652068656164657220282332313833353436290a2d2073642d6a6f75726e616c3a20616c6c6f7720746f207370656369667920636f6d7072657373696f6e20616c676f726974686d207468726f75676820656e7620282332313833353436290a2d20746573743a20616464207465737420636173652074686174206a6f75726e616c2066696c6520697320637265617465642077697468207468652072657175657374656420636f6d7072657373696f6e20616c676f726974686d20282332313833353436290a2d2072756c65733a20646f206e6f74206f6e6c696e6520435055206175746f6d61746963616c6c79206f6e2049424d20706c6174666f726d732028233231343331303729002d2073797374656d643a20537570706f7274204f4f4d506f6c69637920696e2073636f706520756e69747320282332313736393138290a2d2073797374656d643a2044656661756c7420746f204f4f4d506f6c6963793d636f6e74696e756520666f72206c6f67696e2073657373696f6e2073636f70657320282332313736393138290a2d206d616e3a207265776f726b206465736372697074696f6e206f66204f4f4d506f6c6963793d20612062697420282332313736393138290a2d20636f72652c6d616e3a20616464206d697373696e6720696e746567726174696f6e206f66204f4f4d506f6c6963793d20696e2073636f70657320282332313736393138290a2d206d65736f6e3a2053746f72652066757a7a20746573747320696e20737472756374757265642077617920282332313736393138290a2d206d65736f6e3a2047656e65726174652066757a7a657220696e707574732077697468206469726563746976657320282332313736393138290a2d206f73732d66757a7a3a20696e636c7564652067656e65726174656420636f72706f726120696e207468652066696e616c207a69702066696c6520282332313736393138290a2d20756e69743a20496e206367726f757076312c20677261636566756c6c79207465726d696e6174652064656c6567617465642073636f70657320616761696e2028233231383031323029002d206a6f75726e616c2d66696c653a204669782072657475726e2076616c756520696e2062756d705f656e7472795f617272617928292028233231373336383229002d20746573743a2061646420636f76657261676520666f722023323431373720282331393835323838290a2d206c6f67696e642d73657373696f6e3a206d616b652073746f7070696e67206f662069646c652073657373696f6e2076697369626c6520746f2061646d696e732028233231373234303129002d206a6f75726e616c63746c3a2061637475616c6c792072756e20746865207374617469632064657374727563746f727320282332313232353030290a2d206566693a2064726f702065786563757461626c652d737461636b206269742066726f6d202e656c662066696c6520282332313430363436290a2d20696e7374616c6c3a206661696c206561726c792069662073706563696669657220657870616e73696f6e206661696c656420282332313338303831290a2d20746573743a2061646420636f76657261676520666f72202332363436372028233231333830383129002d206e73732d6d79686f73746e616d653a2066697820696e76657274656420636f6e646974696f6e20696e20282332313637343638290a2d206e73732d6d79686f73746e616d653a20646f206e6f742072657475726e20656d70747920726573756c742077697468204e53535f5354415455535f5355434345535320282332313637343638290a2d20736c6565703a2072656e616d652068696265726e6174655f64656c61795f736563202d3e205f7573656320282332313531363132290a2d20736c6565703a2066657463685f6261747465726965735f63617061636974795f62795f6e616d65282920646f6573206e6f742072657475726e202d454e4f454e5420282332313531363132290a2d20736c6565703a2064726f7020756e6e65636573736172792074656d706f72616c2076616961626c6520616e6420696e697469616c697a6174696f6e20282332313531363132290a2d20736c6565703a20696e74726f647563652053757370656e64457374696d6174696f6e5365633d20282332313531363132290a2d20736c6565703a20636f64696e67207374796c65206669786c65747320282332313531363132290a2d20736c6565703a2073696d706c69667920636f646520612062697420282332313531363132290a2d20736c6565703a2066697820696e64656e746174696f6e20282332313531363132290a2d20736c6565703a20656e756d6572617465206f6e6c79206578697374696e6720616e64206e6f6e2d6465766963652062617474657269657320282332313531363132290a2d20636f72653a207768656e2069736f6c6174696e6720746f206120756e69742c20616c736f206b65657020756e6974732072756e6e696e672074686174206172652074726967676572656420627920756e697473207765206b6565702072756e6e696e6720282331393532333738290a2d20756465762f6e65745f69643a20696e74726f64756365206e616d696e6720736368656d6520666f72205248454c2d392e322028233231373035303029002d20756465763a206d616b65206765745f76697274666e5f696e666f28292070726f7669646520706879736963616c205043492064657669636520282332313539343438290a2d20746573743a206d616b652068656c7065725f636865636b5f6465766963655f756e6974732829206c6f6720756e6974206e616d6520282332313338303831290a2d20746573743a20616464206120746573746361736520666f72206c76657874656e6420282332313338303831290a2d20706964313a206669782073656776207472696767657265642062792073746174757320717565727920282332363237392920282332313338303831290a2d20746573743a2063726561746520636f6e66696720756e646572202f72756e20282332313338303831290a2d20746573743a2061646420746573747320666f72206d444e5320616e64204c4c4d4e522073657474696e677320282332313338303831290a2d207265736f6c7665643a20696e74726f6475636520746865205f6c6f63616c646e737374756220616e64205f6c6f63616c646e7370726f7879207370656369616c20686f73746e616d657320666f72203132372e302e302e3534202b203132372e302e302e353320282332313338303831290a2d20746573743a207761697420666f7220746865206d6f6e69746f72696e67207365727669636520746f206265636f6d652061637469766520282332313338303831290a2d20746573743a207375707072657373206563686f20696e206d6f6e69746f725f636865636b5f7272282920282332313338303831290a2d205265766572742022746573743a207761697420666f7220746865206d6f6e69746f72696e67207365727669636520746f206265636f6d65206163746976652220282332313338303831290a2d20746573743a2073686f7720616e6420636865636b20616c6d6f737420616c6c206a6f75726e61[02] 2025-01-17 12:21:30 Database page corruption detected at page 643, retrying... > 6c20656e74726965732073696e6365207468652072656c6576616e7420636f6d6d616e64206265696e6720696e766f6b656420282332313338303831290a2d20746573743a20636f766572204950763620696e20746865207265736f6c766564207465737420737569746520282332313338303831290a2d20746573743a20616464206120636f75706c65206f6620535256207265636f72647320746f20636865636b2073657276696365207265736f6c7574696f6e20282332313338303831290a2d20746573743a206164642061207465737420666f7220746865204f50454e5047504b455920525220282332313338303831290a2d20746573743a20646f6e27742068616e6720696e646566696e6974656c79206f6e206e6f206d6174636820282332313338303831290a2d20746573742d6e646973633a20666978206d656d6c65616b20616e64206664206c65616b20282332313338303831290a2d20746573742d756e69742d6e616d653a20666978206664206c65616b20282332313338303831290a2d20746573743a2062756d7020442d4275732000003896000000002840c66b57bff333acadea911ad4b23300003897736572766963652073746172742074696d656f75742069662077652072756e20776974686f757420616363656c20282332313338303831290a2d20746573743a2062756d702074686520636c69656e742d736964652074696d656f757420696e2073642d6275732061732077656c6c20282332313338303831290a2d20746573743a2062756d702074686520636f6e7461696e657220737061776e2074696d656f757420746f2036307320282332313338303831290a2d206e6574776f726b3a20666978206d656d6c65616b20282332313338303831290a2d2062757363746c3a2066697820696e74726f7370656374696e6720444275732070726f7065727469657320282332313338303831290a2d2062757363746c3a2073696d706c696679207065656b696e6720746865207479706520282332313338303831290a2d207265736f6c76653a2064726f7020726564756e64616e742063616c6c206f6620736f636b65745f697076365f69735f737570706f72746564282920282332313338303831290a2d207265736f6c76653a20696e74726f64756365206c696e6b5f6765745f6c6c6d6e725f737570706f7274282920616e64206c696e6b5f6765745f6d646e735f737570706f7274282920282332313338303831290a2d207265736f6c76653a2070726f766964652065666665637469766520737570706f7274696e67206c6576656c73206f66206d444e5320616e64204c4c4d4e5220282332313338303831290a2d207265736f6c766563746c3a207761726e2069662074686520676c6f62616c206d444e53206f72204c4c4d4e5220737570706f7274206c6576656c206973206c6f776572207468616e2074686520726571756573746564206f6e6520282332313338303831290a2d207265736f6c76653a20656e61626c65207065722d6c696e6b206d444e532073657474696e672062792064656661756c742028233231333830383129002d20737761703a2074656c6c20737761706f6e20746f207265696e697469616c697a652073776170206966206e656564656420282332313531393933290a2d20636f726564756d703a2061646a757374207768697465737061636520282332313535353137290a2d20636f726564756d703a20646f206e6f7420616c6c6f77207573657220746f2061636365737320636f726564756d70732077697468206368616e676564207569642f6769642f6361706162696c697469657320282332313535353137290a2d20526576657274202262617369633a206164642066616c6c6261636b20696e2063686173655f73796d6c696e6b735f616e645f6f70656e646972282920666f72206361736573207768656e202f70726f63206973206e6f74206d6f756e7465642220282332313338303831290a2d20676c7970682d7574696c3a20616464207761726e696e67207369676e207370656369616c20676c79706820282332313338303831290a2d2063686173652d73796d6c696e6b3a207768656e20636f6e76657274696e67206469726563746f7279204f5f5041544820666420746f207265616c2066642c20646f6e277420626f746865722077697468202f70726f632f20282332313338303831290a2d2073797374656d63746c3a207072696e74206120636c656172207761726e696e672069662070656f706c6520696e766f6b652073797374656d63746c20776974686f7574202f70726f632f20282332313338303831290a2d20544553542d36353a20636865636b206361742d636f6e666967206f7065726174696f6e20696e206368726f6f7420282332313338303831290a2d20544553542d36353a20757365205b5b202d76205d5d206d6f726520282332313338303831290a2d2073797374656d63746c3a207761726e20696620747279696e6720746f2064697361626c65206120756e69742077697468206e6f20696e7374616c6c20696e666f20282332313431393739290a2d2073797374656d63746c3a20616c6c6f7720737570707265737320746865207761726e696e67206f66206e6f20696e7374616c6c20696e666f207573696e67202d2d6e6f2d7761726e20282332313431393739290a2d2072706d2f73797374656d642d7570646174652d68656c7065723a20757365202d2d6e6f2d7761726e207768656e2064697361626c696e6720756e69747320282332313431393739290a2d2073797374656d63746c3a207375707072657373207761726e696e672061626f7574206d697373696e67202f70726f632f207768656e202d2d6e6f2d7761726e20282332313431393739290a2d207368656c6c2d636f6d706c6574696f6e3a2073797374656d63746c3a20616464202d2d6e6f2d7761726e20282332313431393739290a2d20636f72652f756e69743a2064726f7020646f75626c656420656d707479206c696e6520282332313630343737290a2d20636f72652f756e69743a2064726f7020646570656e64656e637920746f2074686520756e6974206265696e67206d657267656420282332313630343737290a2d20636f72652f756e69743a20666978206c6f676963206f662064726f7070696e672073656c662d7265666572656e63696e6720646570656e64656e6369657320282332313630343737290a2d20636f72652f756e69743a206d657267652074776f206c6f6f707320696e746f206f6e6520282332313630343737290a2d20746573743a206164642074657374206361736520666f7220737973762d67656e657261746f7220616e6420696e76616c696420646570656e64656e637920282332313630343737290a2d20636f72652f756e69743a206d6572676520756e6974206e616d6573206166746572206d657267696e67206465707320282332313630343737290a2d20636f72652f756e69743a20666978206c6f67206d65737361676520282332313630343737290a2d20746573743a206578706c696369746c792063726561746520746865202f6574632f696e69742e64206469726563746f727920282332313630343737290a2d20746573743a20737570706f72742061206e6f6e2d64656661756c742053797356206469726563746f72792028233231363034373729002d20746573743a20636865636b2069662077652063616e207573652053484131204d4420666f72207369676e696e67206265666f7265207573696e6720697420282332313431393739290a2d20626f6f743a20636c65616e75707320666f72206566697661725f676574282920616e6420667269656e647320282332313431393739290a2d20626f6f743a206669782066616c7365206d617962652d756e696e697469616c697a6564207761726e696e6720282332313431393739290a2d20747265652d776964653a206d6f6465726e697a6174696f6e732077697468205245545f4e4552524e4f282920282332313337353834290a2d2073642d6275733a2068616e646c65202d45494e54522072657475726e2066726f6d206275735f706f6c6c282920282332313337353834290a2d20737464696f2d6272696467653a20646f6e277420626520626f74686572656420776974682045494e545220282332313337353834290a2d207661726c696e6b3a20616c736f2068616e646c652045494e545220677261636566756c6c79207768656e2077616974696e6720666f722045494f207669612070706f6c6c282920282332313337353834290a2d2073642d6e65746c696e6b3a2068616e646c652045494e54522066726f6d20706f6c6c282920677261636566756c6c792c206173207375636365737320282332313337353834290a2d207265736f6c7665643a2068616e646c65202d45494e54522072657475726e65642066726f6d2066645f776169745f666f725f6576656e7428292062657474657220282332313337353834290a2d20686f6d65643a2068616e646c652045494e545220677261636566756c6c79207768656e2077616974696e6720666f7220646576696365206e6f646520282332313337353834290a2d2075746d702d77746d703a20666978206572726f7220696e2063617365206973617474792829206661696c7320282332313337353834290a2d2075746d702d77746d703a2068616e646c652045494e545220677261636566756c6c79207768656e2077616974696e6720746f20777269746520746f2074747920282332313337353834290a2d20696f2d7574696c3a20646f63756d656e742045494e545220736974756174696f6e20612062697420282332313337353834290a2d207465726d696e616c2d7574696c3a20536574204f504f5354207768656e2073657474696e67204f4e4c435220282332313338303831290a2d206367746f703a20446f206e6f742072657772697465202d50206f72202d6b206f7074696f6e73202823; asc al-vacuum: rename function to match struct name (#2182632) - journal-vacuum: use CLEANUP_ARRAY (#2182632) - pam: add call to pam_umask (#2210145) - udev-builtin-net_id: align VF representor names with VF names (#2218886) - pam: add a call to pam_namespace (#2218184) - rules: online CPU automatically on IBM s390x platforms when configured (#2212612) - core/mount: escape invalid UTF8 char in dbus reply (#2208240) - Revert "user: delegate cpu controller, assign weights to user slices" (#2176899) - udev-rules: fix nvme symlink creation on namespace changes (#2172509) - rules: add whitespace after comma before the line continuation (#2172509) - udev: restore compat symlink for nvme devices (#2172509) - rules: drop doubled space (#2172509) - manager: don't taint the host if cgroups v1 is used (#2193456) - core/ 8 (@ kW 3> J?bQ 8 service: when resetting PID also reset known flag (#2210237) - ci: drop systemd-stable from advanced-commit-linter config (#2170883) - ci: trigger `differential-shellcheck` workflow on push (#2100440) - ci: workflow for gathering metadata for source-git automation (#2100440) - ci: first part of the source-git automation - commit linter (#2100440) - ci(Mergify): check CodeQL and build workflows based on changed files (#2100440) - ci: add NOTICE to also update regexp in `.mergify.yml` when updating `paths` property (#2100440) - Support /etc/system-update for OSTree[02] 2025-01-17 12:21:31 Error: failed to read page after 10 retries. File ./acc_zabbix/changelog.ibd seems to be corrupted. > len 16384; hex 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 systems (#2203133) - journal-def: fix type of signature to match the actual field in the Header structure (#2183546) - journal: use compound initialization for journal file Header structure (#2183546) - journald: fix log message (#2183546) - sd-journal: cache results of parsing environment variables (#2183546) - compress: introduce compression_supported() helper function (#2183546) - sd-journal: always use the compression algorithm specified in the header (#2183546) - sd-journal: allow to specify compression algorithm through env (#2183546) - test: add test case that journal file is created with the requested compression algorithm (#2183546) - rules: do not online CPU automatically on IBM platforms (#2143107) - systemd: Support OOMPolicy in scope units (#2176918) - systemd: Default to OOMPolicy=continue for login session scopes (#2176918) - man: rework description of OOMPolicy= a bit (#2176918) - core,man: add missing integration of OOMPolicy= in scopes (#2176918) - meson: Store fuzz tests in structured way (#2176918) - meson: Generate fuzzer inputs with directives (#2176918) - oss-fuzz: include generated corpora in t0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000he final zip file (#2176918) - unit: In cgroupv1, gracefully terminate delegated scopes again (#2180120) - journal-file: Fix return value in000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 bump_entry_array() (#2173682) - test: add coverage for #24177 (#1985288) - logind-session: make stopping of idle session visible to admins (#2172401) - journalctl: actually run the static destructors (#2122500) - efi: drop executable-stack bit from .elf file (#2140646) - install: fail early if specifier expansion failed (#2138081) - test: add coverage for #26467 (#2138081) - nss-myhostname: fix inverted condition in (#2167468) - nss-myhostname: do not return empty result with NSS_STATUS_SUCCESS (#2167468) - sleep: rename hibernate_delay_sec -> _usec (#2151612) - sleep: fetch_batteries_capacity_by_name() does not return -ENOENT (#2151612) - sleep: drop unnecessary temporal vaiable and initialization (#2151612) - sleep: introduce SuspendEstimationSec= (#2151612) - sleep: coding style fixlets (#2151612) - sleep: simplify code a bit (#2151612) - sleep: fix indentation (#2151612) - sleep: enumerate only existing and non-device batteries (#2151612) - core: when isolating to a unit, al0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000so keep units running that are triggered by units we keep running (#1952378) - udev/net_id: introduce naming scheme for RHEL-9.2 (#2170500) - udev: make get_virtfn_info() provide physical PCI device (#2159448) - test: make helper_check_device_units() log unit name (#2138081) - test: add a testcase for lvextend (#2138081) - pid1: fix segv triggered by status query (#26279) (#2138081) - test: create config under /run (#2138081) - test: add tests for mDNS and LLMNR settings (#2138081) - resolved: introduce the _localdnsstub and _localdnsproxy special hostnames for 127.0.0.54 + 127.0.0.53 (#2138081) - test: wait for the monitoring service to become active (#2138081) - test: suppress echo in monitor_check_rr() (#2138081) - Revert "test: wait for the monitoring service to become active" (#2138081) - test: show and check almost all journal entries since the relevant command being invoked (#2138081) - test: cover IPv6 in the resolved test suite (#2138081) - test: add a couple of SRV records to check service resolution (#2138081) - test: add a test for the OPENPGPKEY RR (#2138081) - test: don't hang indefinite000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ly on no match (#2138081) - test-ndisc: fix memleak and fd leak (#2138081) - test-unit-name: fix fd leak (#2138081) - test: bump D-Bus 8 (@ kW 3 3 8 service start timeout if we run without accel (#2138081) - test: bump the client-side timeout in sd-bus as well (#2138081) - test: bump the container spawn timeout to 60s (#2138081) - network: fix memleak (#2138081) - busctl: fix introspecting DBus properties (#2138081) - busctl: simplify peeking the type (#2138081) - resolve: drop redundant call of socket_ipv6_is_supported() (#2138081) - resolve: introduce link_get_llmnr_support() and link_get_mdns_support() (#2138081) - resolve: provide effective supporting levels of mDNS and LLMNR (#2138081) - resolvectl: warn if the global mDNS or LLMNR support level is lower than the requested one (#2138081) - resolve: enable per-link mDNS setting by default (#2138081) - swap: tell swapon to reinitialize swap if needed (#2151993) - coredump: adjust whitespace (#2155517) - coredump: do not allow user to access 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000coredumps with changed uid/gid/capabilities (#2155517) - Revert "basic: add fallback in chase_symlinks_and_opendir() for cases when /proc is not mounted" (#2138081) - glyph-util: add warning sign special glyph (#2138081) - chase-symlink: when converting directory O_PATH fd to real fd, don't bother with /proc/ (#2138081) - systemctl: print a clear warning if people invoke systemctl without /proc/ (#2138081) - TEST-65: check cat-config operation in chroot (#2138081) - TEST-65: use [[ -v ]] more (#2138081) - systemctl: warn if trying to disable a unit with no install info (#2141979) - systemctl: allow suppress the warning of no install info using --no-warn (#2141979) - rpm/systemd-update-helper: use --no-warn when disabling units (#2141979) - systemctl: suppress warning about missing /proc/ when --no-warn (#2141979) - shell-completion: systemctl: add --no-warn (#2141979) - core/unit: drop doubled empty line (#2160477) - core/unit: drop dependency to the unit being merged (#2160477) - core/unit: fix logic of dropping self-referencing dependencies (#2160477) - core/unit: merge two loops into one (#2160477) - test: add test case for sysv-generator and invalid dependency (#2160477) - core/unit: merge unit names after merging deps (#2160477) - core/unit: fix log message (#2160477) - test: explicitly create the /etc/init.d directory (#200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000160477) - test: support a non-default SysV directory (#2160477) - test: check if we can use SHA1 MD for signing before using it (#2141979) - boot: cleanups for efivar_get() and friends (#2141979) - boot: fix false maybe-uninitialized warning (#2141979) - tree-wide: modernizations with RET_NERRNO() (#2137584) - sd-bus: handle -EINTR return from bus_poll() (#2137584) - stdio-bridge: don't be bothered with EINTR (#2137584) - varlink: also handle EINTR gracefully when waiting for EIO via ppoll() (#2137584) - sd-netlink: handle EINTR from poll() gracefully, as success (#2137584) - resolved: handle -EINTR returned from fd_wait_for_event() better (#2137584) - homed: handle EINTR gracefully when waiting for device node (#2137584) - utmp-wtmp: fix error in case isatty() fails (#2137584) - utmp-wtmp: handle EINTR gracefully when waiting to write to tty (#2137584) - io-util: document EINTR situation a bit (#2137584) - terminal-util: Set OPOST when setting ONLCR (#2138081) - cgtop: Do not rewrite -P or -k options (#;0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b30089d40803020300b30089d30803020300b30089d20803020300b30089d10803020300b30089d00803020300b30089cf0803020300b30089ce0803020300b30089cd0803020300b30089cc0803020300b30089cb0803020300b30089ca0803020300b30089c90803020300b30089c80803020300b3[01] 2025-01-17 12:21:31 mariabackup: xtrabackup_copy_datafile() failed. > [00] FATAL ERROR: 2025-01-17 12:21:31 failed to copy datafile.

2 1