- discuss - lists.mariadb.org

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

Which GSSAPI implementation should be used to compile mariadb-connector-c/cpp?
by 张天夫 16 Jan '25

16 Jan '25

I'm trying to compile mariadb-connector-c/cpp on Windows. However, Windows does not provide native GSSAPI. Do I need to look for other implementations? Which is the recommended implementation?

2 1

Inquiry Regarding Parameters of Modified HNSW Algorithm in MariaDB Vector
by kase jojo 13 Jan '25

13 Jan '25

Dear Sir, I hope this message finds you well. I am currently working with the MariaDB vector functionality and am particularly interested in the modified HNSW (MHNSW) algorithm. Specifically, I would like to inquire about the meaning and usage of the parameter "M" in MHNSW, as well as how it compares to other HNSW implementations, such as pgvector. （ https://mariadb.com/kb/en/vector-system-variables/） Typically, HNSW has two key construction parameters: "M" and "efconstruction." However, I noticed that in MHNSW, there doesn't seem to be an "efc" parameter. This has led me to wonder if the "M" parameter in MHNSW has a different meaning or purpose compared to the traditional HNSW "M." Could you kindly clarify the role of the "M" parameter in the modified HNSW algorithm, and how it differs from or is similar to other implementations like pgvector? Thank you for your time and assistance. I look forward to your response. Best regards！

2 1

MariaDb Master/Replica. How to recover replication when reverting Master to an earlier backup?
by Simon Avery 12 Jan '25

12 Jan '25

Hello We have two Mariadb 10.11.10 servers acting as Master and Replica. Both have unique local databases, plus seven that are replicated from Master to Replica with Replicate_Wild_Do_Table: DB1Name.%, DB2Name.% etc The size of the replicated databases is just over 1Tb, with the single largest being almost 500Gb. Both machines are in vmware and on the same network. Yesterday, we hit an issue with the Master which required that vm to be restored to a backup four hours previously. This got Master back in play, but obviously has broken Replication. Traditional wisdom seems to suggest that I need to recreate this replication setup from scratch - ie, stop Master (from changing, ie, close firewall and block clients, flush logs), note the Log Position, and then mysqldump each database. However, due to the size of these databases, that is going to take many hours and we can't accept that downtime for Master. It's occurred to us that we might speed this up by: Stop Master from changing. Note Log Position. Clone Master's vm to Master-Clone. (< 10 minutes) Restart Master. Then we would be at relative leisure to [On Clone] Mysqldump the databases onto a temporary drive. [On Replica] DROP the seven databases. Import the dumped databases from the temporary drive. Update the log position in config and restart the slave user. Then Replica should start syncing from Master again, even if Clone was several days old? Does that sound sensible? These databases have partitions - is that going to cause issues dumping and reimporting them or should I use another method? Any pitfalls? Any alternative ways? Thank you

2 6

Re: Inquiry Regarding Slow Index Creation with MariaDB 11.7 RC (SIFT1M)
by Sergei Golubchik 12 Jan '25

12 Jan '25

Hi, kase, First: please send questions like this to discuss(a)lists.mariadb.org. it's a public mailing list dedicated to MariaDB and how to use it better. I am subscribed, so I'll see you mail there, and you may be sure I will, because it won't be accidentally catched by my spam filter, or sorted out in some obscure folder. Furthermore other subscribers will see your question and could reply if I will be not available (e.g. I could be travelling). Thank you. On Jan 12, kase jojo wrote: > Dear Sir > > I hope you are doing well. I recently read your blog > https://mariadb.com/resources/blog/how-fast-is-mariadb-vector/ and was > particularly impressed by the efficient index-building times demonstrated > in your tests. However, when I attempted similar experiments on MariaDB > 11.7 RC, using the SIFT1M dataset and building an index with M=32, I > noticed that the index creation process was much slower than expected. > > In my case, I have been inserting data into the table gradually, and I > wanted to inquire about the process you mentioned in your blog: "We > build the index slowly as we insert the data row by row." Could you > clarify how this process works? Specifically, I am curious to know if > there are any steps or techniques you followed to ensure such > efficient index construction, as it seems to differ from my > experience. To get faster inserts you need to use a smaller M. Try M=8, for example. It will reduce the recall, and you'll need to increase ef_search to compensate for that. Look at it this way: MariaDB needs to do the work to get good recall. It has to do it *somewhere*. But you can decide where to do it. MariaDB can spend more time doing inserts, build a better index, and search in it quickly. Or it can insert faster, the index will be of worse quality, and it'll need to spend more time searching in it. It's a trade-off and you decide what is more important for your application. See https://github.com/vuvova/ann-benchmarks/blob/dev/ann_benchmarks/algorithms… For faster inserts you can use M=8 and ef_search=800. Of course, always make sure that the mhnsw_max_cache_size is big enough to hold your entire data set. SIFT1M is rather small, 300M should likely be enough. I'd use at least mhnsw_max_cache_size=1G to be safe, it's an upper limit, MariaDB won't use more memory than necessary anyway. Regards, Sergei Chief Architect, MariaDB Server and security(a)mariadb.org

1 0

MariaDB Day @ Brussels 01.02.2025
by Anna Widenius 05 Jan '25

05 Jan '25

Hi All! We are at it again, MariaDB Day is coming to Brussels 1.02.2025 - https://www.meetup.com/mariadb-server/events/305194675/ MariaDB Day events bring together the MariaDB Foundation and community to celebrate and share the latest developments in MariaDB Server. Theme: Vectors, RAG, and everything new in MariaDB Server. With the imminent GA release of MariaDB Vector in MariaDB 11.7, we’re excited to showcase new functionality, real-world use cases, and the promise of Gen AI capabilities within MariaDB Server. Early previews already point to significant enhancements in both features and performance. Compatibility remains a hallmark of MariaDB Server. In many cases, upgrading from MySQL to the latest MariaDB release is simpler than moving to newer MySQL versions, particularly MySQL 8.0 and later. If you’ve attended previous MariaDB Days, you’ll notice a continuing commitment to our core themes. We see databases as a constant source of innovation—one of the many reasons we love gathering with you around FOSDEM each year. Remember to RSVP - places are limited! 💥 https://mariadb.org/projects/mariadb-vector/ Anna Widenius Chief of Staff, MariaDB Foundation

1 0

Re: Question: Performance impact of adding Nullable FK to a new column in large tables
by Guillermo Céspedes Tabárez 03 Jan '25

03 Jan '25

Hi Jeff, Thank you for your response! To clarify, my question is more hypothetical and focused on understanding how the database engine handles this specific scenario. If the column being added is new and starts with all values as NULL, does it make sense to temporarily disable FOREIGN_KEY_CHECKS during the ALTER TABLE operation? My main concern is whether the database performs any additional checks or processes, even though the column is empty (NULL), or if the operation is already optimized and skipping the checks automatically. I'm not debating the use of foreign keys or their impact on runtime performance. I'm specifically curious if disabling FOREIGN_KEY_CHECKS in this situation saves any resources during the ALTER TABLE, or if it's unnecessary because the database doesn't do anything in this case that would benefit from skipping checks. Best regards, Guillermo El vie, 20 dic 2024 a la(s) 5:14 p.m., Jeff Dyke (jeff.dyke(a)gmail.com) escribió: > > While i'm not really sure what performance issues you are referring to. FK are going to have a small performance hit on row changes, but for data integrity, its what you need. When you start to design FKs with Null values, you are talking some of the work off of the database work that can be done for you, and moving it to your developers. Also parent_id should be indexed to assist in select performance. > > Most times that I have seen this done in the past, its normally removed and the index is kept. if parent_ids are going to be duplicated and only null for a period of time, that is a good one to many relationships, that will enforce integrity once populated. > > If you think this will improve overall performance, that is not the goal of Foreign Keys. > > > On Fri, Dec 20, 2024 at 11:03 AM Guillermo Céspedes Tabárez via discuss <discuss(a)lists.mariadb.org> wrote: >> >> Hi, >> >> I’d like to understand the performance impact of adding a FOREIGN KEY >> constraint to a new column in a large table. If the column is nullable >> and defaults to NULL, does the engine perform any checks or >> validations on existing rows? Or is the operation optimized since the >> column starts with all values as NULL? >> >> Here’s a simplified example: >> >> ALTER TABLE child_table >> ADD COLUMN parent_id INT NULL, >> ADD CONSTRAINT fk_child_parent FOREIGN KEY (parent_id) REFERENCES >> parent_table (id) >> ON UPDATE CASCADE ON DELETE SET NULL; >> >> Both child_table and parent_table are large, and the new column >> (parent_id) is empty initially. >> >> Does adding the foreign key have any measurable performance impact in >> this case? Additionally, would it make sense to temporarily disable >> FOREIGN_KEY_CHECKS for this ALTER TABLE operation and then re-enable >> it? Could this save any resources or improve performance? >> >> Thanks for any insights! >> >> Best regards, >> Guillermo. >> _______________________________________________ >> discuss mailing list -- discuss(a)lists.mariadb.org >> To unsubscribe send an email to discuss-leave(a)lists.mariadb.org

2 1

Re: No Mariadb 10.11 enterprise?
by highclass99 22 Dec '24

22 Dec '24

I did look into purchasing MariaDB Enterprise Server in the past for a service I was helping, but in the end stuck with MariaDB Community Server, because I was worried we might have trouble migrating back to the community server version if needed as the client was not 100% sure they could keep paying for all the instances they needed in the future. If on a certain MariaDB Enterprise version, would it be binary compatible with the same MariaDB Community Server version? (as long as not using features only in the MariaDB Community Server version) Thank you. Have a nice day. On Wed, Dec 18, 2024 at 9:27 PM Sergei Golubchik <serg(a)mariadb.com> wrote: > Hi, highclass99, > > On Dec 14, highclass99 via discuss wrote: > > > > I noticed on https://mariadb.com/docs/server/release-notes/ that after > > MariaDB 10.6 enterprise there is no MariaDB 10.11 enterprise but only > 11.4 > > enterprise release candidate right now. > > > > Does this mean there will be no MariaDB 10.11 enterprise? > > Is there a reason for MariaDB to be skipping the LTS version for > enterprise? > > Yes, it does. Yes, there is. > > While MariaDB Community Server's focus is on rapidly delivering new > features to users - which is why there is a rolling release line, > MariaDB Enterprise Server focus is on stability and long life cycle. > > In other words, MariaDB Enterprise Server is maintained longer and is > not released as often. It still gets new features through carefully > selected backports, see any release notes, e.g. > > https://mariadb.com/resources/blog/mariadb-enterprise-server-q4-2024-mainte… > > At least this is the current model. It might change in the future. > > Regards, > Sergei > Chief Architect, MariaDB Server > and security(a)mariadb.org >

1 0

Question: Performance impact of adding Nullable FK to a new column in large tables
by Guillermo Céspedes Tabárez 20 Dec '24

20 Dec '24

Hi, I’d like to understand the performance impact of adding a FOREIGN KEY constraint to a new column in a large table. If the column is nullable and defaults to NULL, does the engine perform any checks or validations on existing rows? Or is the operation optimized since the column starts with all values as NULL? Here’s a simplified example: ALTER TABLE child_table ADD COLUMN parent_id INT NULL, ADD CONSTRAINT fk_child_parent FOREIGN KEY (parent_id) REFERENCES parent_table (id) ON UPDATE CASCADE ON DELETE SET NULL; Both child_table and parent_table are large, and the new column (parent_id) is empty initially. Does adding the foreign key have any measurable performance impact in this case? Additionally, would it make sense to temporarily disable FOREIGN_KEY_CHECKS for this ALTER TABLE operation and then re-enable it? Could this save any resources or improve performance? Thanks for any insights! Best regards, Guillermo.

1 0

No Mariadb 10.11 enterprise?
by highclass99 13 Dec '24

13 Dec '24

Hi, I noticed on https://mariadb.com/docs/server/release-notes/ that after MariaDB 10.6 enterprise there is no MariaDB 10.11 enterprise but only 11.4 enterprise release candidate right now. Does this mean there will be no MariaDB 10.11 enterprise? Is there a reason for MariaDB to be skipping the LTS version for enterprise? Thank you.

1 0

Support for galera clusters
by Dan O'Reilly 05 Dec '24

05 Dec '24

I can't find a place in the galera docs for a problem I'm having, so asking here. I have a 3 node mariadb Galera cluster (2 db's and an arbitrator node). On the arbitrator, when I start gardb manually and specify the log file as -l "/var/log/gardb.log" all is fine. If I try starting it as a service (RHEL 9) using the LOG_FILE in the config file, it always encounters "Failed to open '/var/log/gardbd.log' for appending: 2 (no such file or directory" I can find ZERO documentation on what's going on there." This is gardb version 26.4.14.r, installed as part of mariadb-server-galera.

1 0

frm files were deleted, how to recover?
by lkhaajav＠limes.kr 27 Nov '24

27 Nov '24

Hi everybody? Today is the first snow day of the year in Seoul, every thing is white outside, it is a beautiful day. Some of *.frm and *.ibd files were deleted forever accidently. Those cannot be recovered. I used some file-recovery tools but failed. Also data was partitioned. Is there any way to recover *.ibd partitioned files without *.frm ? MariaDB version is 10.7.3. Storage Engine is InnoDB. I tried innodb_force_recovery=6, also created same structure frm files and used discard, import, but partitioned tables cannot be supported for discard and import. Please help me!

1 0

Slow Log Rotation Hang Bug
by Gordan Bobic 19 Nov '24

19 Nov '24

I've been doing some testing with various versions of MySQL and MariaDB regarding slow log rotation. And it looks like MariaDB (tested 10.4, 10.5, 10.6 so far) suffers from a bug. Setup: sloq_query_log=1 long_query_time=0 # sysbench oltp_read_write --threads=$(nproc) Action: mv slow.log slow.log.1 MariaDB [(none)]> flush slow logs; ^^ This never returns (never as in I haven't tried waiting for > 10 minutes). On MySQL 5.5 this is instantaneous. On 5.6 - 8.0 it takes a few seconds, worst case I measured over the weekend is 77s, which is pretty terrible, but with MariaDB 10.3 - 10.6 it never seems to complete at all. If I kill sysbench, it completes immediately. On 10.3 it works, in line with MySQL 5.6 - 8.0. This seems like a rather significant bug.

2 4

MariaDB 10.5 - add replication to existing installation
by Dan O'Reilly 15 Nov '24

15 Nov '24

When I try to add replication to an existing installation, mariadb refuses to start (I'm a novice at MariaDB). This is on RHEL 9. This is my server.cnf: # These groups are read by MariaDB server. # Use it for options that only the server (but not clients) should see # # See the examples of server my.cnf files in /usr/share/mysql/ # # this is read by the standalone daemon and embedded servers [server] # this is only for the mysqld standalone daemon # Settings user and group are ignored when systemd is used. # If you need to run mysqld under a different user or group, # customize your systemd unit file for mysqld/mariadb according to the # instructions in http://fedoraproject.org/wiki/Systemd [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/log/mariadb/mariadb.log pid-file=/run/mariadb/mariadb.pid # next stuff copied from the original zabbix 5 server.cnf default-storage-engine=innodb innodb_autoinc_lock_mode=2 innodb_buffer_pool_size=1GB innodb_doublewrite=1 innodb_file_per_table=1 innodb_flush_method = O_DIRECT innodb_log_file_size=128M long_query_time=1 max-allowed-packet=16M max_connections=800 max_heap_table_size=256M performance_schema=on query_cache_size=0 query_cache_type=0 slow_query_log=1 slow_query_log_file=/var/lib/mysql/slowlog/mysql-slow.log thread-cache-size=50 tmp_table_size=512M # # * Galera-related settings # [galera] # Mandatory settings #wsrep_on=ON #wsrep_provider= #wsrep_cluster_address= #binlog_format=row #default_storage_engine=InnoDB #innodb_autoinc_lock_mode=2 # # Allow server to accept connections on all interfaces. # bind-address=0.0.0.0 # # Optional setting #wsrep_slave_threads=1 #innodb_flush_log_at_trx_commit=0 # this is only for embedded server [embedded] # This group is only read by MariaDB servers, not by MySQL. # If you use the same .cnf file for MySQL and MariaDB, # you can put MariaDB-only options here [mariadb] # This group is only read by MariaDB-10.5 servers. # If you use the same .cnf file for MariaDB of different versions, # use this group for options that older servers don't understand [mariadb-10.5] # server-id=1 log_bin = /var/log/mysql/mysql-bin.log log_bin_index =/var/log/mysql/mysql-bin.log.index relay_log = /var/log/mysql/mysql-relay-bin relay_log_index = /var/log/mysql/mysql-relay-bin.index The error I get is: # systemctl status mariadb × mariadb.service - MariaDB 10.5 database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; preset: disabled) Active: failed (Result: exit-code) since Mon 2024-11-11 16:31:02 MST; 12min ago Duration: 2h 35min 21.402s Docs: man:mariadbd(8) https://mariadb.com/kb/en/library/systemd/ Process: 426050 ExecStartPre=/usr/libexec/mariadb-check-socket (code=exited, status=0/SUCCESS) Process: 426072 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir mariadb.service (code=exited, status=1/FAILURE) CPU: 281ms Nov 11 16:31:02 tmv1zbdb01 mariadb-prepare-db-dir[426111]: the maria-discuss email list at https://launchpad.net/~maria-discuss Nov 11 16:31:02 tmv1zbdb01 mariadb-prepare-db-dir[426111]: Please check all of the above before submitting a bug report Nov 11 16:31:02 tmv1zbdb01 mariadb-prepare-db-dir[426111]: at https://mariadb.org/jira Nov 11 16:31:02 tmv1zbdb01 mariadb-prepare-db-dir[426072]: Initialization of MariaDB database failed. Nov 11 16:31:02 tmv1zbdb01 mariadb-prepare-db-dir[426072]: Perhaps /etc/my.cnf is misconfigured or there is some problem with permissions of /var/lib/mysql. Nov 11 16:31:02 tmv1zbdb01 mariadb-prepare-db-dir[426072]: Initialization of MariaDB database was not finished successfully. Nov 11 16:31:02 tmv1zbdb01 mariadb-prepare-db-dir[426072]: Files created so far will be removed. Nov 11 16:31:02 tmv1zbdb01 systemd[1]: mariadb.service: Control process exited, code=exited, status=1/FAILURE Nov 11 16:31:02 tmv1zbdb01 systemd[1]: mariadb.service: Failed with result 'exit-code'. Nov 11 16:31:02 tmv1zbdb01 systemd[1]: Failed to start MariaDB 10.5 database server.

3 3

how to backup MyRocks Database without InnoDB Using mariadb-backup
by i18n.site 12 Nov '24

12 Nov '24

I am facing an issue while attempting to back up my MariaDB database, which is entirely based on the MyRocks storage engine. My MariaDB was compiled without InnoDB support, and I am using `mariadb-backup` to perform the backup. However, I encounter the following error: ❯ sudo -u mysql /usr/local/mysql/bin/mariadb-backup --backup --target-dir=/tmp/rebuild_slave [00] 2024-11-13 06:37:55 Connecting to MariaDB server host: localhost, user: mysql, password: not set, port: 2883, socket: /run/mysqld/mysqld.sock [00] 2024-11-13 06:37:56 Using server version 11.4.2-MariaDB-log /usr/local/mysql/bin/mariadb-backup based on MariaDB server 11.4.2-MariaDB Linux (x86_64) [00] 2024-11-13 06:37:56 uses posix_fadvise(). [00] 2024-11-13 06:37:56 cd to /mnt/data/i18n/mariadb/data/ [00] 2024-11-13 06:37:56 open files limit requested 0, set to 108224 [00] 2024-11-13 06:37:56 mariabackup: using the following InnoDB configuration: [00] 2024-11-13 06:37:56 innodb_data_home_dir = . [00] 2024-11-13 06:37:56 innodb_data_file_path = ibdata1:10M:autoextend [00] 2024-11-13 06:37:56 innodb_log_group_home_dir = . 2024-11-13 6:37:56 0 [Note] InnoDB: Number of transaction pools: 1 2024-11-13 6:37:56 0 [ERROR] InnoDB: File ./ib_logfile0 was not found [00] 2024-11-13 06:37:56 Error: cannot read redo log header ❯ sudo -u mysql /usr/local/mysql/bin/mariadb-backup --backup --target-dir=/tmp/rebuild_slave --skip-innodb-backup /usr/local/mysql/bin/mariadb-backup: unknown option '--skip-innodb-backup' ❯ sudo -u mysql /usr/local/mysql/bin/mariadb-backup --backup --target-dir=/tmp/rebuild_slave --rocksdb-backup [00] 2024-11-13 06:38:53 Connecting to MariaDB server host: localhost, user: mysql, password: not set, port: 2883, socket: /run/mysqld/mysqld.sock [00] 2024-11-13 06:38:53 Using server version 11.4.2-MariaDB-log /usr/local/mysql/bin/mariadb-backup based on MariaDB server 11.4.2-MariaDB Linux (x86_64) [00] 2024-11-13 06:38:53 uses posix_fadvise(). [00] 2024-11-13 06:38:53 cd to /mnt/data/i18n/mariadb/data/ [00] 2024-11-13 06:38:53 open files limit requested 0, set to 108224 [00] 2024-11-13 06:38:53 mariabackup: using the following InnoDB configuration: [00] 2024-11-13 06:38:53 innodb_data_home_dir = . [00] 2024-11-13 06:38:53 innodb_data_file_path = ibdata1:10M:autoextend [00] 2024-11-13 06:38:53 innodb_log_group_home_dir = . 2024-11-13 6:38:53 0 [Note] InnoDB: Number of transaction pools: 1 2024-11-13 6:38:53 0 [ERROR] InnoDB: File ./ib_logfile0 was not found [00] 2024-11-13 06:38:53 Error: cannot read redo log header ❯ mariadb-backup -v mariadb-backup based on MariaDB server 11.4.2-MariaDB Linux (x86_64) ────── i18N.Site : MarkDown Translate / Website Solution ( 翻译&建站工具 )

1 0

(no subject)
by i18n.site 12 Nov '24

12 Nov '24

I am facing an issue while attempting to back up my MariaDB database, which is entirely based on the MyRocks storage engine. My MariaDB was compiled without InnoDB support, and I am using `mariadb-backup` to perform the backup. However, I encounter the following error: ❯ sudo -u mysql /usr/local/mysql/bin/mariadb-backup --backup --target-dir=/tmp/rebuild_slave [00] 2024-11-13 06:37:55 Connecting to MariaDB server host: localhost, user: mysql, password: not set, port: 2883, socket: /run/mysqld/mysqld.sock [00] 2024-11-13 06:37:56 Using server version 11.4.2-MariaDB-log /usr/local/mysql/bin/mariadb-backup based on MariaDB server 11.4.2-MariaDB Linux (x86_64) [00] 2024-11-13 06:37:56 uses posix_fadvise(). [00] 2024-11-13 06:37:56 cd to /mnt/data/i18n/mariadb/data/ [00] 2024-11-13 06:37:56 open files limit requested 0, set to 108224 [00] 2024-11-13 06:37:56 mariabackup: using the following InnoDB configuration: [00] 2024-11-13 06:37:56 innodb_data_home_dir = . [00] 2024-11-13 06:37:56 innodb_data_file_path = ibdata1:10M:autoextend [00] 2024-11-13 06:37:56 innodb_log_group_home_dir = . 2024-11-13 6:37:56 0 [Note] InnoDB: Number of transaction pools: 1 2024-11-13 6:37:56 0 [ERROR] InnoDB: File ./ib_logfile0 was not found [00] 2024-11-13 06:37:56 Error: cannot read redo log header ❯ sudo -u mysql /usr/local/mysql/bin/mariadb-backup --backup --target-dir=/tmp/rebuild_slave --skip-innodb-backup /usr/local/mysql/bin/mariadb-backup: unknown option '--skip-innodb-backup' ❯ sudo -u mysql /usr/local/mysql/bin/mariadb-backup --backup --target-dir=/tmp/rebuild_slave --rocksdb-backup [00] 2024-11-13 06:38:53 Connecting to MariaDB server host: localhost, user: mysql, password: not set, port: 2883, socket: /run/mysqld/mysqld.sock [00] 2024-11-13 06:38:53 Using server version 11.4.2-MariaDB-log /usr/local/mysql/bin/mariadb-backup based on MariaDB server 11.4.2-MariaDB Linux (x86_64) [00] 2024-11-13 06:38:53 uses posix_fadvise(). [00] 2024-11-13 06:38:53 cd to /mnt/data/i18n/mariadb/data/ [00] 2024-11-13 06:38:53 open files limit requested 0, set to 108224 [00] 2024-11-13 06:38:53 mariabackup: using the following InnoDB configuration: [00] 2024-11-13 06:38:53 innodb_data_home_dir = . [00] 2024-11-13 06:38:53 innodb_data_file_path = ibdata1:10M:autoextend [00] 2024-11-13 06:38:53 innodb_log_group_home_dir = . 2024-11-13 6:38:53 0 [Note] InnoDB: Number of transaction pools: 1 2024-11-13 6:38:53 0 [ERROR] InnoDB: File ./ib_logfile0 was not found [00] 2024-11-13 06:38:53 Error: cannot read redo log header ❯ mariadb-backup -v mariadb-backup based on MariaDB server 11.4.2-MariaDB Linux (x86_64) ────── i18N.Site : MarkDown Translate / Website Solution ( 翻译&建站工具 )

1 0

Monitoring mariaDB through SNMP
by Noah 04 Nov '24

04 Nov '24

Ahoy List Members, I hope you are well. Is there a good guide that explains how to set up monitoring mariaDB via SNMP? Cheers, Noah

3 2

Migrate MySQL5.7 to MariaDB 10.4, then to MariaDB 10.11 Failed
by edwin.chan＠checkit.net 30 Oct '24

30 Oct '24

Hi, I am going to migrate our existing MySQL5.7 to MariaDB 10.11.9. I setup a new Windows server that installed MySQL 5.7, MariaDB 10.4.34 and MariaDB 10.11.9 without create a new instance. I copied the data directory of MySQL5.7 from existing Windows server to the new server for migration test. First, I am able to start the MySQL5.7 on the new server. Then, I upgrade the MySQL5.7 to MariaDB 10.4.34 successfully using mysql_upgrade_service.exe which under MariaDB 10.4.34 bin directory. But failed at the last step that upgrade MariaDB 10.4.34 to MariaDB 10.11.9 using mariadb-upgrade-service.exe which under MariaDB 10.11.9 bin directory. From the error log, got below message 2024-10-03 16:17:39 0 [Note] InnoDB: Buffer pool(s) load completed at 241003 16:17:39 241003 16:17:40 [ERROR] mysqld got exception 0xc0000005 ; 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 From the upgrade log, got below message Phase 3/8: Running 'mysql_fix_privilege_tables' ERROR 2017 (HY000): Can't open named pipe to host: . pipe: mysql_upgrade_service_3564 (2) FATAL ERROR: Upgrade failed Checked named pipe enabled and local client able to connect using named pipe at each stage. Any idea why upgrade failed? When upgrade, MariaDB start the instance with socket which is not same as the socket option in my.ini. In this case, it start with socket mysql_upgrade_service_3564; I tried few times the last 4 numeric digits are not fixed and change every time. Thanks.

5 6

Logging options to debug SSL problem
by Andrew Wood 14 Oct '24

14 Oct '24

Hi Is there a way to get the server to log verbosely everything to do with connection attempts in order to try and debug why a client keeps getting error 2026 SSL connection error: socket layer receive error? There is currently nothing being logged on the server other than: [Warning] Aborted connection 332 to db: 'unconnected' user: 'unauthenticated' host: '192.168.253.231' (This connection closed normally without authentication) SHOW GLOBAL VARIABLES LIKE 'tls_version'; gives TLSv1.1,TLSv1.2,TLSv1.3 and the client is based on a relatively recent version of libmysqlclient so Im struggling to understand what is going wrong without some more detailed logging. Thanks Andrew

3 3

Performance questions after Migrating from MariaDB 5.5.68 to 10.11.6 (and 9)
by cyusedfzfb 10 Oct '24

10 Oct '24

Dear MariaDB List Readers, I hope formatting will survive...i tried to make this as readable as possible. Due to our ongoing migration from RHEL7 to RHEL9, we are also upgrading some databases from MariaDB 5.5.68 (on RHEL7) to MariaDB 10.11.6 (on RHEL9). During this process, we've noticed a significant performance drop, particularly with UPDATE and DELETE operations. To investigate this further and rule out external factors, I created a single RHEL9 VM and downloaded both the x86_64/systemd versions of MariaDB 5.5.68 and 10.11.9 from MariaDB Downloads. (https://mariadb.org/download) I installed both versions on the same VirtualBox VM, using default configurations, and placed them on the same partition (/usr/local). I followed the installation instructions in the INSTALL-BINARY file. I then ran a benchmark on both versions using a variation of this PHP benchmark script: https://github.com/sergix44/php-benchmark-script. Here are the results: *MariaDB 5.5.68*: Server version: 5.5.68-MariaDB MariaDB Server mysql::ping,0.0002 mysql::select_version,0.1299 mysql::select_all,0.6270 mysql::select_cursor,0.8542 mysql::seq_insert,2.0182 mysql::bulk_insert,0.0204 mysql::update,0.0005 mysql::update_with_index,0.0005 mysql::transaction_insert,0.0014 mysql::indexes,0.0000 mysql::delete,0.0005 mysql::select_version::q/s,15403 mysql::select_all::q/s,3190 mysql::seq_insert::q/s,991 mysql::update::q/s,3895386 mysql::update_with_index::q/s,4105436 mysql::transaction_insert::t/s,1460821 mysql::delete::q/s,4436065 Total time: 13.2027 s Peak memory usage: 23.82 MiB *MariaDB 10.11.9*: Server version: 10.11.9-MariaDB MariaDB Server mysql::ping,0.0001 mysql::select_version,0.1268 mysql::select_all,0.6435 mysql::select_cursor,0.8352 mysql::seq_insert,2.2696 mysql::bulk_insert,0.6556 mysql::update,1.4104 mysql::update_with_index,0.3981 mysql::transaction_insert,2.5425 mysql::indexes,0.2353 mysql::delete,2.2246 mysql::select_version::q/s,15772 mysql::select_all::q/s,3108 mysql::seq_insert::q/s,881 mysql::update::q/s,1418 mysql::update_with_index::q/s,8963 mysql::transaction_insert::t/s,787 mysql::delete::q/s,899 Total time: 20.9426 s Peak memory usage: 23.82 MiB The key observations: - **UPDATE performance:** - 5.5.68: *3,895,386* q/s - 10.11.9: *1,418* q/s - **UPDATE with index:** - 5.5.68: *4,105,436* q/s - 10.11.9: *8,963* q/s - **DELETE performance:** - 5.5.68: *4,436,065* q/s - 10.11.9: *899* q/s I also tested MariaDB 10.11.6, and the results were similar to 10.11.9. Our web application feels noticeably slower, and the benchmark results seem to confirm this. Is this drastic performance drop expected with newer MariaDB versions? While we are aware of tuning options (like `innodb_buffer_pool_size`, file system mount options, `innodb_flush_log_at_trx_commit`, etc.), both versions were run with default settings and no tuning. How can it be that MariaDB 5.5.68 is performing several orders of magnitude faster than 10.11.x for these specific operations? Best regards, MJ To end, and to be complete: find below the actual script used to create the stats: <?php $initialRowCount = 1000; $mysqli = null; setup(function ($args) use (&$mysqli, $initialRowCount) { if (!extension_loaded('mysqli')) { print('The mysqli extension is not loaded' . PHP_EOL); return; } if ($args['mysql_host'] === null || $args['mysql_user'] === null || $args['mysql_password'] === null) { print('The --mysql_host=, --mysql_user=, and --mysql_password= arguments are required' . PHP_EOL); return; } $mysqli = new mysqli($args['mysql_host'], $args['mysql_user'], $args['mysql_password'], null, isset($args['mysql_port']) ? $args['mysql_port'] : 3306); if ($mysqli->connect_error) { printf("Mysql Connect Error (%s) %s\n", $mysqli->connect_errno, $mysqli->connect_error); return; } // drop database $mysqli->query("DROP DATABASE IF EXISTS `bench_test`"); // create database $mysqli->query("CREATE DATABASE IF NOT EXISTS `bench_test`"); $mysqli->select_db('bench_test'); $mysqli->query("CREATE TABLE IF NOT EXISTS `bench_test`.`test` (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255))"); for ($i = 0; $i < $initialRowCount; $i++) { $values[] = "('test$i')"; } $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES " . implode(',', $values)); }); teardown(function () use (&$mysqli) { if ($mysqli === null) { return; } $mysqli->query("DROP DATABASE IF EXISTS `bench_test`"); $mysqli->close(); }); return [ 'ping' => function () use (&$mysqli) { if ($mysqli === null) { return INF; } $mysqli->ping(); return 1; }, 'select_version' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("SELECT VERSION()"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'select_all' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("SELECT * FROM `bench_test`.`test`"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'select_cursor' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; for ($i = 0; $i < $count; $i++) { $result = $mysqli->query("SELECT * FROM `bench_test`.`test`"); while ($row = $result->fetch_assoc()) { } $result->close(); } return $i; }, 'seq_insert' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES ('test')"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'bulk_insert' => function ($multiplier = 1, $count = 100000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $values = []; for ($i = 0; $i < $count; $i++) { $values[] = "('test$i')"; } $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES " . implode(',', $values)); return $i; }, 'update' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("UPDATE `bench_test`.`test` SET name = 'test' WHERE id = '$i'"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, 'update_with_index' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $mysqli->query("CREATE INDEX idx ON `bench_test`.`test` (id)"); $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("UPDATE `bench_test`.`test` SET name = 'test' WHERE id = '$i'"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); $mysqli->query("DROP INDEX idx ON `bench_test`.`test`"); return $i; }, 'transaction_insert' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->begin_transaction(); $mysqli->query("INSERT INTO `bench_test`.`test` (name) VALUES ('test')"); $mysqli->commit(); } extraStat('t/s', round($count / (StopWatch::time() - $time))); return $i; }, 'indexes' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $mysqli->query("CREATE INDEX idx_name ON `bench_test`.`test` (name)"); $mysqli->query("DROP INDEX idx_name ON `bench_test`.`test`"); return 1; }, 'delete' => function ($multiplier = 1, $count = 1000) use (&$mysqli) { if ($mysqli === null) { return INF; } $count = $count * $multiplier; $time = StopWatch::time(); for ($i = 0; $i < $count; $i++) { $mysqli->query("DELETE FROM `bench_test`.`test` WHERE id = '$i'"); } extraStat('q/s', round($count / (StopWatch::time() - $time))); return $i; }, ];

5 9

mariadb 10.6.17 + galera-26.4.19
by Jaco Kroon 07 Oct '24

07 Oct '24

Hi, We're observing the following crash using galera and mariadb versions as per subject. Usually only one of the three nodes will go down, but last night two went down within minutes of each other resulting in a fairly nasty outage. Given the frequency of these crashes (about one once a month) I highly suspect we're doing something wrong causing us to run into this, but not others. So any advise appreciated. Stack trace as per logs: 241007 1:01:25 [ERROR] mysqld 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 We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.6.17-MariaDB-log source revision: 15c75ad083a55e198ae78324f22970694b72f22b key_buffer_size=536870912 read_buffer_size=1048576 max_used_connections=522 max_threads=10002 thread_count=83 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10498887186 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f675c000c68 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f7f78056da8 thread_stack 0x49000 /usr/sbin/mysqld(my_print_stacktrace+0x32)[0x5632cb5f2212] /usr/sbin/mysqld(handle_fatal_signal+0x2b3)[0x5632cb133db3] /lib64/libc.so.6(+0x3c760)[0x7f7f7b653760] /usr/sbin/mysqld(+0x8ee692)[0x5632cb44b692] /usr/sbin/mysqld(+0x8ef5cd)[0x5632cb44c5cd] /usr/sbin/mysqld(+0x8acfa5)[0x5632cb409fa5] /usr/sbin/mysqld(+0x24e630)[0x5632cadab630] /usr/sbin/mysqld(+0x24e6b5)[0x5632cadab6b5] /usr/sbin/mysqld(+0x949418)[0x5632cb4a6418] /usr/sbin/mysqld(+0x960b34)[0x5632cb4bdb34] /usr/sbin/mysqld(+0x8b9e7c)[0x5632cb416e7c] /usr/sbin/mysqld(_ZN7handler10ha_rnd_posEPhS0_+0x232)[0x5632cb13b022] /usr/sbin/mysqld(_ZN14Rows_log_event8find_rowEP14rpl_group_info+0x3e4)[0x5632cb2624c4] /usr/sbin/mysqld(_ZN21Delete_rows_log_event11do_exec_rowEP14rpl_group_info+0x142)[0x5632cb2629b2] /usr/sbin/mysqld(_ZN14Rows_log_event14do_apply_eventEP14rpl_group_info+0x35f)[0x5632cb255c9f] /usr/sbin/mysqld(_Z18wsrep_apply_eventsP3THDP14Relay_log_infoPKvm+0x1fd)[0x5632cb3def8d] /usr/sbin/mysqld(+0x868ff0)[0x5632cb3c5ff0] /usr/sbin/mysqld(_ZN21Wsrep_applier_service15apply_write_setERKN5wsrep7ws_metaERKNS0_12const_bufferERNS0_14mutable_bufferE+0xb5)[0x5632cb3c6ba5] /usr/sbin/mysqld(+0xb0c921)[0x5632cb669921] /usr/sbin/mysqld(+0xb1dfd6)[0x5632cb67afd6] /usr/lib64/galera/libgalera_smm.so(+0x60724)[0x7f7f7b260724] /usr/lib64/galera/libgalera_smm.so(+0x6fa67)[0x7f7f7b26fa67] /usr/lib64/galera/libgalera_smm.so(+0x74d65)[0x7f7f7b274d65] /usr/lib64/galera/libgalera_smm.so(+0x9fdc3)[0x7f7f7b29fdc3] /usr/lib64/galera/libgalera_smm.so(+0xa098e)[0x7f7f7b2a098e] /usr/lib64/galera/libgalera_smm.so(+0x75200)[0x7f7f7b275200] /usr/lib64/galera/libgalera_smm.so(+0x4f35f)[0x7f7f7b24f35f] /usr/sbin/mysqld(_ZN5wsrep18wsrep_provider_v2611run_applierEPNS_21high_priority_serviceE+0x12)[0x5632cb67b652] /usr/sbin/mysqld(+0x8842d1)[0x5632cb3e12d1] /usr/sbin/mysqld(_Z15start_wsrep_THDPv+0x276)[0x5632cb3d0d16] /usr/sbin/mysqld(+0x80e941)[0x5632cb36b941] /lib64/libc.so.6(+0x8ad22)[0x7f7f7b6a1d22] /lib64/libc.so.6(+0x10698c)[0x7f7f7b71d98c] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7efdea05db): delete from `jobs` where `id` = 808933436 Connection ID (thread ID): 2 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off,hash_join_cardinality=off,cset_narrowing=off The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /var/lib/mysql Resource Limits: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 1031460 1031460 processes Max open files 91983 91983 files Max locked memory 8388608 8388608 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 1031460 1031460 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Core pattern: core Kernel version: Linux version 6.4.12-uls (root@sysrescue) (gcc (Gentoo 13.2.1_p20230826 p7) 13.2.1 20230826, GNU ld (Gentoo 2.41 p2) 2.41.0) #2 SMP PREEMPT_DYNAMIC Thu Jan 4 20:10:49 SAST 2024 I'm unable to locate the referenced core file or I'd already have pulled that into gdb. Any advise or pointers appreciated. I do notice there are galera updates, and a number of mariadb upgrades available. For galera this looks like improvements in logging, so probably not the cause of the crash, and for mariadb in 10.6.18 these items stand out for me: Server crashes in JOIN_CACHE::write_record_data upon EXPLAIN with subqueries and constant tables (MDEV-21102 <https://jira.mariadb.org/browse/MDEV-21102>) - but the stack trace doesn't match. Server crash in Rows_log_event::update_sequence upon replaying binary log (MDEV-31779 <https://jira.mariadb.org/browse/MDEV-31779>) - this looks feasible. If anyone can confirm my conjecture that would be great. We'd want to test 10.11 or even 11.4 in a non-production environment before making a big jump to one of those versions in production. Kind regards, Jaco

1 0

mysql_native_password authentication plugin
by cyusedfzfb 06 Oct '24

06 Oct '24

Hi, Just a quick question: we understand that mysql_native_password authentication plugin has become deprecated, and yes: we are in the process of moving to caching_sha2_password. We read everywhere that mysql_native_password is "subject to removal in a future version of MySQL" Can anyone say how soon that removal is going to be? (as for now it seems just a change of the default authentication mechanism, and I cannot find a date/year/version for *actual* removal) (and yes I did google) :-) Thanks!

3 2

Cannot backup database
by Marc Chamberlin 06 Oct '24

06 Oct '24

Hello - I am wanting to backup my databases and until now I haven't experienced any difficulties. I am working on an OpenSuSE 15.4 system and wanting to upgrade it which is why I want to backup the databases first. The version of mariadb is : > >> quasar:/srv/mysql #mariadb -V >> mariadb Ver 15.1 Distrib 10.6.15-MariaDB, for Linux (x86_64) using >> EditLine wrapper >> > But now I am hitting a new snag, when I try to run the backup script I > get the following response - > >> quasar:/srv/mysql #./mysqlbackup.sh >> mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ >> `EVENT_CATALOG`, `EVENT_SCHEMA`, `EVENT_NAME`, `DEFINER`, >> `TIME_ZONE`, `EVENT_BODY`, `EVENT_DEFINIT >> ION`, `EVENT_TYPE`, `EXECUTE_AT`, `INTERVAL_VALUE`, `INTERVAL_FIELD`, >> `SQL_MODE`, `STARTS`, `ENDS`, `STATUS`, `ON_COMPLETION`, `CREATED`, >> `LAST_ALTERED`, `LAST_ >> EXECUTED`, `EVENT_COMMENT`, `ORIGINATOR`, `CHARACTER_SET_CLIENT`, >> `COLLATION_CONNECTION`, `DATABASE_COLLATION` FROM `EVENTS`': Cannot >> proceed, because event sch >> eduler is disabled (1577) >> > The mysql.log file is showing these 2 error messages also - > >> 2024-10-05 14:43:30 0 [ERROR] Incorrect definition of table >> mysql.event: expected column 'definer' at position 3 to have type >> varchar(, found type char(141). >> 2024-10-05 14:43:30 0 [ERROR] mysqld: Event Scheduler: An error >> occurred when initializing system tables. Disabling the Event Scheduler. > My Duck Duck Go searches on the internet suggested I put the following > line in the file my.cnf > >> event_scheduler=ON > but no joy. Also, most of my internet searches hit on solutions that > were designed for running mariadb in a docker container. I am NOT > using docker, don't even know how to, and don't want solutions that > require docker. Too much to try an grok at this time for me. > > One interesting item of note is that on OpenSuSE (at least) the > systemd file mariadb.service runs both the install and the upgrade > services before starting the actual mysql daemon. Here is an excerpt > from mariadb.service that shows this - > >> [Service] >> ExecStartPre=/usr/lib/mysql/mysql-systemd-helper install >> ExecStartPre=/usr/lib/mysql/mysql-systemd-helper upgrade >> ExecStart=/usr/lib/mysql/mysql-systemd-helper start > Anyone got any bright and wonderful ideas on how to make mariadb a > happy camper that will allow me to do a database backup? > > Many thanks in advance for those who can guide me back to the mariadb > light! Marc C... > >

2 1

Re: Migrate MySQL5.7 to MariaDB 10.4, then to MariaDB 10.11 Failed
by Edwin Chan 04 Oct '24

04 Oct '24

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

1 0

Re: Migrate MySQL5.7 to MariaDB 10.4, then to MariaDB 10.11 Failed
by Edwin Chan 04 Oct '24

04 Oct '24

Hi Marko, Attached the mysqld.dmp. Thanks. Regards, Edwin Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

1 0

unexpected swap usage for mysqld (but mariadb) process
by cyusedfzfb 29 Sep '24

29 Sep '24

Hi all! New here, signed up just new, to discuss an interesting mariadb behaviour we are seeing, related to mariadb unexpectedly using swap space. Look at this example: RHEL 8.10, running mariadb-server-utils.x86_64 3:10.5.22-1.module+el8.8.0+20134+a92c7654: > [user@db ~]$ free -g > total used free shared buff/cache > available > Mem: 187 9 11 0 165 175 > Swap: 3 3 0 and: > top - 08:52:46 up 39 days, 15:50, 2 users, load average: 1.70, 2.05, > 1.99 > Tasks: 616 total, 2 running, 614 sleeping, 0 stopped, 0 zombie > %Cpu(s): 6.0 us, 0.8 sy, 0.0 ni, 88.2 id, 4.7 wa, 0.1 hi, 0.1 > si, 0.0 st > MiB Mem : 191529.7 total, 11761.7 free, 9764.9 used, 170003.1 > buff/cache > MiB Swap: 4096.0 total, 1006.1 free, 3089.9 used. 179429.5 avail > Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > COMMAND *SWAP * > 1952811 mysql 20 0 14.4g 5.0g 15172 S 65.7 2.7 9663:14 > mysqld* 1.7g * > 2934963 root 20 0 5208 2056 1408 S 8.9 0.0 10:39.29 > gzip 0 > 2934962 root 20 0 33612 8268 6960 S 7.9 0.0 2:35.31 > mysqldump 0 while: > [user@db ~]$ cat /proc/sys/vm/swappiness > 1 We could (we should..) allocate more ram to mariadb, but the point is: there is plenty of RAM available, and there always has been, since boot. And yet, mariadb is using all swap. I guess this has no performance impact, probably the swapped pages are not actually used, but zabbix does not like 100% swap usage. And frankly: neither do I. Why? Can anyone here explain? Swappiness set to 1...is mariadb ignoring swappiness..? Is there something else we can configure..? I read some older posts on ram/swap, and here is some data, requested in that older thread: > [user@db ~]$ sudo ps -o pid,vsz,comm `pgrep mysqld` > PID VSZ COMMAND > 1952811 15117612 mysqld and > [user@db ~]$ for file in /proc/*/status ; do awk > '/VmSwap|Name/{printf $2 " " $3}END{ > > print ""}' $file; done | sort -k 2 -n -r | grep mysql > mysqld 1982672 kB We are seeing similar behaviour on another machines, running more recent mariadb version: 10.5.22-MariaDB MariaDB Server: > [user@db_another ~]$ free -g > total used free shared buff/cache > available > Mem: 62 40 0 1 21 20 > Swap: 4 3 1 Again: enough RAM available, and swap is used 3/4, mostly by MariaDB. Hope the provided information is enough. Let me know if there is anything else I can provide. Looking forward for any insight or help on the matter. :-) Thanks! MJ

5 7

InnoDB database corrupt after unplaned server restart
by Rainer Dorsch 22 Sep '24

22 Sep '24

Hello, I am using mariadb as backend for nextcloud. After an unplanned server restart by my provider I see in the log this error message repeating many times: Sep 21 23:14:06 contabo.bokomoko.de mariadbd[267649]: 2024-09-21 23:14:06 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/ kb/en/library/innodb-recovery-modes/ for information about forcing recovery. Sep 21 23:14:06 contabo.bokomoko.de mariadbd[267649]: 2024-09-21 23:14:06 0 [ERROR] InnoDB: Page [page id: space=0, page number=300] log sequence number 572290405174 is in the future! Current system log sequence number 572290220157. I have a backup of /var/lib/mysql from before the issue. The files which are currently in /var/lib/mysql seem to be stuck with a timestamp from immediately after the reboot. Can anybody advise on a good recovery strategy? Any hint or advice is welcome. Many thanks Rainer -- Rainer Dorsch http://bokomoko.de/

1 0

Database schema error while upgrading Koha 24.05 in Ubuntu 24.04 Noble LTS
by Md Monirul Islam Ansari 20 Sep '24

20 Sep '24

Dear folks, Greetings from Monirul this side, During an upgrade of Koha to version 24.05.03-1, the process failed due to a database access error. The upgrade script was unable to connect to the MySQL/MariaDB database, suggesting a potential issue with database permissions or configuration. Steps to Reproduce: Attempt to upgrade Koha-common package to version 24.05.03-1 Run sudo apt-get install mariadb-server Confirm the installation/upgrade process Observed Behavior: The upgrade process fails during the database schema upgrade step An error message indicates that access is denied for the Koha database user Error Message: "DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: DBI connect('database=koha_monirul;host=localhost;port=3306','koha_monirul',...) failed: Access denied for user 'koha_monirul'@'localhost' (using password: YES) at /usr/share/koha/lib/Koha/Database.pm line 91. at /usr/share/koha/lib/Koha/Database.pm line 139" Environment: Koha version being upgraded to: 24.05.03-1 Database: MariaDB (version 1:10.11.8-0ubuntu0.24.04.1) Operating System: Ubuntu (likely 24.04 based on package versions)

2 1

Joining two tables on a list of values
by Gingko 14 Sep '24

14 Sep '24

Hello, I would like to know if is there some (efficient!) way to join two tables on a list of values contained in (likely a single column) of the joined table, whatever form could have this list of values ? For example, I have a main table containing: main_table: +------------+------------------+------+-----+------------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+------------------+------+-----+------------+----------------+ | index | int(11) | NO | PRI | 0 | | | to_join | int(11) | NO | | 0 | | | <other fields, irrelevant> | | || | +------------+------------------+------+-----+------------+----------------+ … and a secondary table containing: joined_table: +------------+------------------+------+-----+------------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+------------------+------+-----+------------+----------------+ | index | int(11) | NO | PRI | | auto_increment | | int_list | <list_of_ints> | YES | | (empty) | | | <other fields, irrelevant> | | | | | +------------+------------------+------+-----+------------+----------------+ We could suppose, here, as a simple test case, that main_table has five rows where to_join contains respectively 1, 2, 3, 4, and 5, and the joined_table has a single row with the single column int_list combining 2 and 4 in any form (but of course, this list could actually have any length). I'd like to join these tables using a statement like: SELECT <anything> FROM main_table AS M LEFT JOIN joined_table AS J ON M.to_join <some_operator to> J.int_list; … in such a way that main_table would be joined to joined_table using any value contained in int_list, and the statement is expected to give two rows as a result. I tried to set int_list as a TINYTEXT containing "2,4" and use: SELECT <anything> FROM main_table AS M LEFT JOIN joined_table AS J ON M.to_join IN (J.int_list); … but this doesn't work, of course, my comma separated list is seen as a whole single value. I also tried, still using TINYTEXT, the list as "[2][4]" and use: SELECT <anything> FROM main_table AS M LEFT JOIN joined_table AS J ON J.int_listLIKE CONCAT('%[', M.to_join , ']%'); This works (more or less), but it is excruciatingly slow, especially knowing that main_table can actually contain millions of rows, and joined_table several thousands. Is there a better solution for doing that? As the final goal implies, somewhere later, associating to_join in main_table, via int_list, to the index auto increment primary key of the joined_table, using multiple rows there is not an option. Regards, Gingko

5 5

Fulltext index tokenization rules / DOC_ID
by wknauf＠hg-online.de 14 Sep '24

14 Sep '24

Hi all, first question: is there a document that describes the rules how MariaDB builds the fulltext index words? I set "innodb_ft_min_token_size=1" to include also one letter words in the index. But this does not seem to work for words like "D'Artagnan": the "d" letter is not found in "information_schema.INNODB_FT_INDEX_TABLE". It works for "D Artagnan". So I assume that single letters that are followed by a quote are ignored when building the index? You could also post the link to the source code file, but I don't know whether my C knowledge is sufficient ;-) Second question: the doc (https://mariadb.com/kb/en/information-schema-innodb_ft_index_table-table/) states that "information_schema.INNODB_FT_INDEX_TABLE.doc_id" matches to the id column of the original table: "DOC_ID: Document ID of the newly added row, either an appropriate ID column or an internal InnoDB value." But this did not happen for me - the doc_id values do not match my ID column. I tried the datatypes "int" and "bigint". Best regards Wolfgang

4 4

MariaDB ServerFest in Berlin on September 17
by Kristian Nielsen 26 Aug '24

26 Aug '24

The next MariaDB ServerFest will take place in Berlin, Germany. The event is on September 17, 2024, and is generously hosted by MariaDB Foundation sponsor Ionos: https://mariadb.org/fest-2024-berlin/ The event is open to all. I was at the MariaDB ServerFest in Helsinki last Autumn, and I really liked the close interaction with the many interesting participants: big and advanced users, developers, university students, service providers, etc. It is an excellent opportunity to meet many of the core developers, and hopefully a lot of other great people! I will be presenting at the event myself; my talk is titled: "MariaDB Replication – Fantastically Flexible and Fragile". I very much welcome questions during my talks, so feel free to prepare questions for me about anything replication. - Kristian.

2 1

MariaDB server crash status=11/SEGV on version 10.6.19
by zxc072211＠gmail.com 21 Aug '24

21 Aug '24

Hi, First, I apologize if my English isn't perfect. After upgrading my MariaDB server from version 10.6.18 to 10.6.19. I encountered an issue. When I execute a "SELECT ... FROM ( SELECT ... ) x WHERE x.colume1 .." statement, the server returns the error: "ERROR 2013 (HY000): Lost connection to server during query." I checked the `/var/log/messages` and found this message: "mariadb.service: Main process exited, code=killed, status=11/SEGV.". I used core dumping to investigate further and found that the stack frame count reaches #12171. The error at #0 is "... Item::build_clone ... at /usr/src/debug/MariaDB-/src_0/sql/item.h:1928". The previous stack frames keep repeating two frames: #1 Item_func_case_simple::do_build_clone ... at /usr/src/debug/MariaDB-/src_0/sql/item_cmpfunc.h:2448 #2 ... Item::build_clone ... at /usr/src/debug/MariaDB-/src_0/sql/item.h:1928 My OS is Rocky Linux 8.10. The MariaDB server versions where I encountered this issue are 10.6.19 and 10.11.9. The MariaDB server version without issues is 10.6.18. Has anyone else encountered this problem? Thanks in advance for any help.

2 2

External MyISAM partitions
by Jan Křístek 07 Aug '24

07 Aug '24

Hi, We have an old instance of MariaDB 10.3.9/10.3.39, with historical data. Every month I copy an old MyISAM partition (binary files) from the same version of the engine (but a different instance) to a big volume and replace an empty partition in the database with symlinks to the newly copied two files (MYD, MYI - when the engine is stopped). I have been doing it for a year or two, checking each time the data are accessible afterwards. This month it happened, that the data are not accessible anymore, and the database throwing an exception: *Got error 140: "Wrong create options" from storage engine MyISAM.* I tried doing it in a new instance, each time I replace a partition with a link to file elsewhere, the error appeared again. Does anyone have any ideas, why it's showing the error and how to avoid it? I cannot recall changing anything in the database configuration, upgrading any database, or doing any other changes. Thanks for any help you can provide, Jan

4 7

Query Performance Drops 10.3 -> 10.5 - Query Optimizer Refusing Index
by Michael Caplan 02 Aug '24

02 Aug '24

HI there, Looking for some advice. A common query "structure" that performed well in 10.3 is showing a significant performance decrease in 10.5.24. The root cause seems to be 10.5's refusal to use a key. The table in question is has a "key => value" like structure: CREATE TABLE `cases_meta` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `case_id` int(10) unsigned NOT NULL, `key` varchar(50) NOT NULL, `value` mediumtext DEFAULT NULL, PRIMARY KEY (`id`), KEY `key` (`key`), KEY `fk_caes_meta_1` (`case_id`), CONSTRAINT `fk_caes_meta_1` FOREIGN KEY (`case_id`) REFERENCES `cases` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci The query in question simply is looking for a `key` with a specific value: SELECT * FROM cases_meta AS cm WHERE cm.`key` = 'PAN_NUMBER' AND cm.`value` = '153566' In this example, the table has 2.8 million records. In 10.5, it skips the `key` key, and grinds through 2.8 million records: ANALYZE: { "query_block": { "select_id": 1, "r_loops": 1, "r_total_time_ms": 2743.92693, "table": { "table_name": "cm", "access_type": "ALL", "possible_keys": ["key"], "r_loops": 1, "rows": 1004130, "r_rows": 2820048, "r_table_time_ms": 2548.916341, "r_other_time_ms": 195.0068087, "filtered": 30.31918144, "r_filtered": 0, "attached_condition": "ddx_lab_801615.cm.`key` = 'PAN_NUMBER' and ddx_lab_801615.cm.`value` = '153566'" } } } In 10.3, it uses the `key` key, and reads through a radically smaller subset of tables to fetch the result: ANALYZE: { "query_block": { "select_id": 1, "r_loops": 1, "r_total_time_ms": 357.84, "table": { "table_name": "cm", "access_type": "ref", "possible_keys": ["key"], "key": "key", "key_length": "152", "used_key_parts": ["key"], "ref": ["const"], "r_loops": 1, "rows": 304484, "r_rows": 155123, "r_total_time_ms": 340.94, "filtered": 100, "r_filtered": 0, "index_condition": "ddx_lab_801615.cm.`key` = 'PAN_NUMBER'", "attached_condition": "ddx_lab_801615.cm.`value` = '153566'" } } } I'm not sure why 10.5 is taking this substandard approach. Adding a USE INDEX (`key`) seems to have no effect in 10.5 either, it just skips the index. Any ideas? Thanks, Mike Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended only for the individual(s) addressed in the message and may contain proprietary and confidential information. If you are not the intended recipient, you should not disseminate, distribute, or copy this e-mail. Please notify the sender and destroy this message. WARNING: Computer viruses can be transmitted via email. The recipient should scan this email before opening it. The company accepts no liability for any damage caused by any virus transmitted by this email. Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended only for the individual(s) addressed in the message and may contain proprietary and confidential information. If you are not the intended recipient, you should not disseminate, distribute, or copy this e-mail. Please notify the sender and destroy this message. WARNING: Computer viruses can be transmitted via email. The recipient should scan this email before opening it. The company accepts no liability for any damage caused by any virus transmitted by this email.

2 3

mariadb connector/c client not using SSL
by Chris Ross (cross2) 30 Jul '24

30 Jul '24

Hey there. I am trying to get a local application which uses the mariadb client library to connect to a server with SSL. On my client system, I have added “ssl-ca” and “ssl-verify-server-cert” to the [client] section of my my.cnf. I can see these in effect with both “mariadb --help” and with “my_print_defaults client”. And, using mariadb client itself with all of the right connection parameters (host/port/username/port/schema) it connects just fine. However, a program of mine which uses mysql_real_connect() fails, reporting “Access denied for user ‘foo’@’ip’ (using password: YES)”. This is, I assume, because the user on the database side requires ssl, and my client is not using ssl. I’ve added: (void)mysql_optionsv(conn, MYSQL_READ_DEFAULT_FILE, NULL); Into my sources before calling mysql_real_connect(). I thought that would make it pull the params from the config file, and all should be good. But, that’s clearly not enough. Can someone help me figure out what I’m missing? Thank you. * Chris

3 10

insert multiple SET type values in prepared statement?
by J.D. 28 Jul '24

28 Jul '24

Trying to insert multiple values of a SET type column using (MariaDB) prepared statements, but keep running into "Data truncated for column <columnN>" no matter how the multi-value string is formatted. Processing is done using PHP-8.2. ... INSERT INTO <table> SET ....<columnN=?> ....; $BindValuesArray[<columnN>]="'value1,value2,value3'"; $BindVarsArray[]=&${$<columnN>}; $BindParamTypes.="s"; ... extract($BindValuesArray); So, trying to insert a (multi-valued) "list string" into a SET type column.

1 0

Poor fulltext index performance in conjunction with order by.
by gava100＠gmail.com 26 Jul '24

26 Jul '24

Hello All, I'm looking for a way to improve a query using fulltext index and so far, couldn't find any good solution. I have an alert table (described below) with around 6 million records and a full-text index on these two columns (ALERT_COMMENT, ALERT_SOURCE). I'd like to query the latest 30 received alerts based on a string content. Currently, I am proceeding with the following query: SELECT * FROM Alert WHERE MATCH(ALERT_COMMENT, ALERT_SOURCE) AGAINST ('string content' IN BOOLEAN MODE) > 0.0 ORDER BY ALERT_ID DESC LIMIT 30; However, this query is taking minutes to retrieve the data, likely due to poor performance of the full-text index in conjunction with the ORDER BY statement. When I remove the 'ORDER BY' statement, the result is returned in seconds. Do you have any suggestions for improving the retrieval time for this query? Below is the table structure: CREATE TABLE `Alert` ( `ALERT_ID` int(11) NOT NULL AUTO_INCREMENT, `SITE_ID` varchar(50) NOT NULL, `ALERT_LEVEL` int(4) NOT NULL, `RECEIVED_TIME` datetime NOT NULL, `OCCURRED_TIME` datetime NOT NULL, `ALERT_SOURCE` varchar(50) NOT NULL, `ALERT_COMMENT` varchar(1024) NOT NULL, PRIMARY KEY (`ALERT_ID`), FULLTEXT KEY `IX_ALERT_COMMENT_SOURCE_CODE` (`ALERT_COMMENT`, `ALERT_SOURCE`) ); Thanks in Advance Gava

1 0

Cannot Start MariaDB
by gw1500 22 Jul '24

22 Jul '24

I've just installed maria on ubuntu but cannot start mariadb: *× mariadb.service - MariaDB 10.6.18 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2024-07-21 16:12:47 UTC; 54s ago Docs: man:mariadbd(8) https://mariadb.com/kb/en/library/systemd/ Process: 3483 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS) Process: 3484 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Process: 3486 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set> Process: 3515 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE) Main PID: 3515 (code=exited, status=1/FAILURE) Status: "MariaDB server is down" CPU: 114ms Jul 21 16:12:47 dap002 mariadbd[3515]: 2024-07-21 16:12:47 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error Jul 21 16:12:47 dap002 mariadbd[3515]: 2024-07-21 16:12:47 0 [Note] InnoDB: Starting shutdown... Jul 21 16:12:47 dap002 mariadbd[3515]: 2024-07-21 16:12:47 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. Jul 21 16:12:47 dap002 mariadbd[3515]: 2024-07-21 16:12:47 0 [Note] Plugin 'FEEDBACK' is disabled. Jul 21 16:12:47 dap002 mariadbd[3515]: 2024-07-21 16:12:47 0 [ERROR] Could not open mysql.plugin table: "Unknown storage engine 'Aria'". Some plugins may be not loaded Jul 21 16:12:47 dap002 mariadbd[3515]: 2024-07-21 16:12:47 0 [ERROR] Failed to initialize plugins. Jul 21 16:12:47 dap002 mariadbd[3515]: 2024-07-21 16:12:47 0 [ERROR] Aborting Jul 21 16:12:47 dap002 systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE Jul 21 16:12:47 dap002 systemd[1]: mariadb.service: Failed with result 'exit-code'. Jul 21 16:12:47 dap002 systemd[1]: Failed to start MariaDB 10.6.18 database server. *I searched for this error (Unknown storage engine Aria) but the solution is to remove the log from /var/log/mysql. However, that directory is empty. If ubuntu puts that log somewhere else I cannot find it. Can someone point me in the right direction for resolving this? TIA.

3 5

MaxScale BSL licensing
by stephan.vos＠metacom.net 12 Jul '24

12 Jul '24

Hi, I need some clarification with regards to the BSL license for MaxScale: Licensed Work: MariaDB MaxScale (TM) version 22.08 The Licensed Work is (c) 2022 MariaDB Corporation Ab Additional Use Grant: You may use the Licensed Work when your application uses the Licensed Work with a total of less than three server instances in production. The the server instances above refer to the servers on which MaxScale is installed or does it refer to the number of database servers that each MaxScale instance monitors. For example can I have MaxScale installed on 5 application servers which then monitors two or less database servers without a license?

3 4

Upgrade from MariaDB 10.6 to 11.4
by stephan.vos＠metacom.net 05 Jul '24

05 Jul '24

I only see details on the website on how to upgrade from 11.6 to 10.11. https://mariadb.com/kb/en/upgrading-from-mariadb-10-6-to-mariadb-10-11/ Does this mean in order to get to 11.4 safely I first have to upgrade to 10.11 and then to 11.4? Has anyone managed to upgrade directly from 10.6 to 11.4 without issues?

3 4

MyISAM packed tables is uncompressed when index is added.
by Vassilis Virvilis 02 Jul '24

02 Jul '24

Hi, The question: Is uncompressing a myisam table when adding an index the expected behavior? Here is the story: I have a very big table so I thought to compress it. I used myisampack which worked great. The table.MYD shrank in size. myisamchk -ddv shows the table as compressed. I noticed the documentation that urges to run: myisamchk -rq after myisampack and I thought: Maybe I shouldn't create any indices on the uncompressed table since myisamchk will redo the work. But if I try to add an index to the compressed table suddenly it gets expanded to its original size and myisamchk -ddv does report the table a uncompressed. So the only solution is to: 1. add the indices in the uncompressed table 2. compress the table 3. run myisamchk -rq [--sort-index --analyze --parallel-recover --tmpdir=/somewhere/with/a/lot/of/space] 4. mysqladmin flush-tables; But this duplicates the index creations step. So is this the expected behavior? * If yes: why? Expanding the table behind the user's back is surprising... * If no: Should I report it as a bug? Here is how to replicate: #DROP TABLE IF EXISTS txxx; CREATE TABLE txxx (id INT, value TEXT); INSERT INTO txxx SELECT 1, REPEAT('A', 65536); *# Let's go to shell *ls -ltr txxx.* -rw-rw---- 1 mysql mysql 466 Jun 30 19:34 txxx.frm -rw-rw---- 1 mysql mysql 1024 Jun 30 19:40 txxx.MYI -rw-rw---- 1 mysql mysql *65548* Jun 30 19:40 txxx.MYD <-- 64K cool *# cool! let's compress *myisampack -f txxx Compressing txxx.MYD: (1 records) - Calculating statistics - Compressing file 87.42% ls -ltr txxx.* -rw-rw---- 1 mysql mysql 466 Jun 30 19:34 txxx.frm -rw-rw---- 1 mysql mysql *8255* Jun 30 19:40 txxx.MYD <-- 8K cool -rw-rw---- 1 mysql mysql 1024 Jun 30 19:41 txxx.MYI # great it is compressed *# because documentation says so: *myisamchk -qr txxx - check record delete-chain - recovering (with keycache) MyISAM-table 'txxx' Data records: 1 ls -ltr txxx.* -rw-rw---- 1 mysql mysql 466 Jun 30 19:34 txxx.frm -rw-rw---- 1 mysql mysql *8255* Jun 30 19:40 txxx.MYD <-- Still compressed -rw-rw---- 1 mysql mysql 1024 Jun 30 19:43 txxx.MYI myisamchk -ddv txxx MyISAM file: txxx Record format: *Compressed* <-------------------------------------!!!! OK Character set: utf8mb3_general_ci (33) File-version: 1 Creation time: 2024-06-30 19:40:36 Recover time: 2024-06-30 19:43:52 Status: checked Checksum: 2613455662 Data records: 1 Deleted blocks: 0 Datafile parts: 1 Deleted data: 0 Datafile pointer (bytes): 6 Keyfile pointer (bytes): 3 Datafile length: 8248 Keyfile length: 1024 Max datafile length: 281474976710654 Max keyfile length: 17179868159 Recordlength: 15 table description: Key Start Len Index Type Rec/key Root Blocksize ro *# Now Let's add the index* ALTER TABLE txxx ADD INDEX(id); *# Shell again *ls -ltr txxx.* -rw-rw---- 1 mysql mysql 958 Jun 30 19:47 txxx.frm -rw-rw---- 1 mysql mysql *65548* Jun 30 19:47 txxx.MYD <--- *Oups - now it is uncompressed* -rw-rw---- 1 mysql mysql 2048 Jun 30 19:47 txxx.MYI myisamchk -ddv txxx MyISAM file: txxx Record format: *Packed* <----------------------------- *Why*? Character set: utf8mb3_general_ci (33) File-version: 1 Creation time: 2024-06-30 19:47:30 Status: changed Data records: 1 Deleted blocks: 0 Datafile parts: 1 Deleted data: 0 Datafile pointer (bytes): 6 Keyfile pointer (bytes): 6 Datafile length: 65548 Keyfile length: 2048 Max datafile length: 281474976710654 Max keyfile length: 288230376151710719 Recordlength: 16 table description: Key Start Len Index Type Rec/key Root Blocksize 1 2 4 multip. long NULL 0 1024 1024

2 2

Can Mariabackup import from a Percona Xtrabackup backup?
by Bryan K. Walton 18 Jun '24

18 Jun '24

Hi, We have a Maria DB 5.5 replica set running on Centos 7. With this OS version about to become end of life, we are planning an upgrade of our replica set to RHEL 9 and Maria DB 10.5. My general plan is to add a new replica secondary to the mix, running Maria DB 10.5 and then promote that server to be primary and replace the other replica members with a new secondary that is also running Maria DB 10.5. My question is, since Mariabackup didn't exist in Maria DB 5.5, is it possible to backup our existing Maria databases with Percona Xtrabackup and then have Mariabackup (from Maria DB 10.5) import that backup on the new server? Thanks, Bryan

2 2

No repo access since two days
by mail＠alexander-palm.de 09 Jun '24

09 Jun '24

Hello there! Sorry, I have no idea where to post this, I hope it's the right place. Since two days I get 403 forbidden errors by apt update at all URLs from mariadb.com I try to get out the reason but I can't. What I have done: - check the trusted.d keys and reinstall it - check if the VHost provider is the problem. So I install a clean new VM at Strato with Ubuntu 22.04 and 24.04 and get the same error on both by using the 'mariadb_repo_setup' script. - install a clean VM at Hetzner whit ubuntu 24.04 and get the same problem by using the 'mariadb_repo_setup' script. I have no Idee what's happend. If I use the URL via curl there is no error. But I can see that the Request to https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/ubuntu/dists/jammy/In… was redirectet to some cloudflare services with some tokens and timestamps and so on perhaps apt cannot handle that? 3 days before there was no issue with this configuration. Here is a output-example: bash mariadb_repo_setup # [info] Checking for script prerequisites. # [info] MariaDB Server version 11.4 is valid # [info] Repository file successfully written to /etc/apt/sources.list.d/mariadb.list # [info] Adding trusted package signing keys... # [info] Running apt-get update... E: The repository 'http://downloads.mariadb.com/Tools/ubuntu jammy InRelease' is not signed. E: Failed to fetch http://downloads.mariadb.com/Tools/ubuntu/dists/jammy/InRelease 403 Forbidden [IP: 2606:4700::6812:8718 80] E: Failed to fetch https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/ubuntu/dists/jammy/In… 403 Forbidden [IP: 2606:4700::6811:bf0e 443] E: The repository 'https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/ubuntu jammy InRelease' is not signed. E: Failed to fetch https://dlm.mariadb.com/repo/maxscale/latest/apt/dists/jammy/InRelease 403 Forbidden [IP: 2606:4700::6811:bf0e 443] E: The repository 'https://dlm.mariadb.com/repo/maxscale/latest/apt jammy InRelease' is not signed. # [error] Failed to add trusted package signing keys Anyone an idea? Thanks, Alex

1 1

Deleted database still present on replica
by Dave Hall 06 Jun '24

06 Jun '24

Hello, If this is not the right place for this question, please feel free to redirect... I am running MariaDB version 10.5.23 in a master/replica configuration with 4 replicas. I recently experienced a failure that required me to restore the DBs on all of my DB systems from backup, including all of my replicas. Somehow in the course of this process I have some databases on my some of my replicas that have been deleted on the master. What is the best way to remove these without confusing or breaking the replication process? Thanks. -Dave -- Dave Hall Binghamton University kdhall(a)binghamton.edu

2 1

Aborted connection 0 to db: 'unconnected' user: 'unauthenticated' host: 'connecting host' (Too many connections)
by Rhys.Campbell＠swisscom.com 22 May '24

22 May '24

Hello All, We have a vendor app that attempts a large number of connections and creating the following error in the MariaDB logs (10.11) Aborted connection 0 to db: 'unconnected' user: 'unauthenticated' host: 'connecting host' (Too many connections) Could this error be cause by the vendor app reusing connections that have been idled out on the server side? Rhys

2 1

Deadlock Errors
by Scott Canaan 10 May '24

10 May '24

We have a 3-node Galera cluster running MariaDB 10.5.23. A couple months ago the cluster had an issue and one of my coworkers handled it. We have several cron jobs that run against the databases to gather statistics and other information. One of those jobs runs every 15 minutes. Since the last issue, one SQL in that script has been throwing a deadlock error on two of the three nodes in the cluster: ERROR 1213 (40001) at line 14: Deadlock found when trying to get lock; try restarting transaction I've been monitoring and I don't see the job running more than once at the same time on the same server. The SQL that it is failing on is: insert into rit_mdb_track_logins select report_date, user, count(*) logins from rit_mdb_track_login_detail group by report_date, user; I've run this SQL manually and it works fine. I'm not sure where to go from here. Scott Canaan '88 Sr Database Administrator Information & Technology Services Finance & Administration Rochester Institute of Technology o: (585) 475-7886 | f: (585) 475-7520 srcdco(a)rit.edu<mailto:srcdco@rit.edu> | c: (585) 339-8659 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

3 5

TCMalloc with Maria and THPs
by Simon Avery 08 May '24

08 May '24

Hello I'm looking to test tcmalloc for use on our ~80 Maria 10.11.[6-7] servers, running either Rocky 8/9 or Debian 12. A few years ago we moved to using jemalloc which helped resolve or reduce many of the memory leaks on these servers from using the distro's default malloc. We still have a couple of machines where Maria eventually uses all the memory until oomkiller steps in - although we've largely mitigated that by adopting weekly restarts for them. Thanks to Sergei Golubchik for his most useful post here on the 5th on the subject of memory leaks, which has got us looking at tcmalloc and also raises the question of Transparent Huge Pages. Sergei cites several reliable sources recommending turning them off for MariaDb and similar databases. Now - my question; tcmalloc's documentation on tuning at https://google.github.io/tcmalloc/tuning.html says "TCMalloc heavily relies on Transparent Huge Pages (THP)." And explains it's built and tested with THPs enabled and seems to strongly recommend leaving them on. That contradicts the above articles, leaving me confused about which path is best practice. It seems that THP's should be on as advised by tcmalloc, but also off when running MariaDb. The true answer possibly depends on which has the highest priority in terms of database-specific performance and the ability to manage the memory tightly. What are others' views, please? I'm searching in particular for best practice and real world experiences with tcmalloc. Also - if it's unlikely to improve upon jemalloc. 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

2 3

Detect INSERT vs REPLACE in BEFORE INSERT trigger
by Alex Hermann 06 May '24

06 May '24

Hi, Is there a (built-in) way to detect from within a BEFORE INSERT trigger whether it was triggered by an INSERT or REPLACE statement? I could surround every REPLACE statement with setting and clearing a variable. Problem is that this could easily be forgotten as there are multiple applications accessing the table. I'd rather not wrap access in a stored procedure or worse. What will not work is to do a SELECT (tailored to every UNIQUE key) to determine if a record will be replaced. I do not need to know if a record _will_ be replaced, just that the intention is that it _can_ be replaced. Background: the trigger does a validation that is not enforcable via a UNIQUE key. This precludes an INSERT ... ON DUPLICATE KEY UPDATE ... construction. When the validation finds a conflicting row, the query must fail when the _intent_ is to add a new record (INSERT), but succeed when the _intent_ is to replace (REPLACE) that row. -- Regards, Alex Hermann

3 2