December 2023 - discuss - lists.mariadb.org

Question regarding AMD EPYC servers and MariaDB
by highclass99 06 Feb '24

06 Feb '24

Hello, In the past when 2nd gen EPYC's were launching and beating Intel servers on most benchmarks, I visited a MariaDB conference and when I asked a senior MariaDB engineer, and asked whether he recommended AMD servers. At that time, he recommended Intel for MariaDB, because MariaDB had much more Intel testing equipment and was optimized for Intel. I am curious whether that is still the case, and whether MariaDB should be more optimized for Intel? For example, would AMD EPYC 7763 vs Intel Platinum 8380, would one be recommended over the other for MariaDB? (of course cores, and workload differ, but on a general perspective) Thank you.

3 3

Repeatable read anomalies
by Kyle Kingsbury 16 Jan '24

16 Jan '24

Hi y'all! I've just completed an analysis of isolation levels in MySQL. The report focuses on MySQL, but the test suite runs against MariaDB as well. MariaDB exhibits all the same behaviors--"Repeatable Read" allows a whole bunch of anomalies that should be prohibited under Repeatable Read, including G2-item, G-single (even without predicates), non-repeatable reads, violations of Monotonic Atomic View, etc. Figured this might be of interest to the list. https://jepsen.io/analyses/mysql-8.0.34 I'm also curious whether this is widely-understood behavior in the MariaDB community, or if it's news to most people. The extant literature doesn't really seem to discuss these behaviors much, but maybe there's more tacit knowledge among experts? Sincerely, --Kyle

7 19

Creating Replica With Rsync (But It Fails)
by Michael Caplan 30 Dec '23

30 Dec '23

Hi there, I am attempting to create a replica from a MariaDB 10.3.31 master. The replicate is running MariaDB 10.3.39 on the same OS (Ubuntu 20.04) and like hardware with identical MariaDB configuration. The strategy I'm using to create the replica is one that I have done before using earlier version of MariaDB and MySQL. But this time it is failing. It roughly looks like this: 1. rsync /var/lib/mysql from master to replica 2. On master: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; 3. On master: Shutdown 4. rerun rsync from master to replica; then restart master 5. Start mariadb on replica 6. CHANGE MASTER on replica 7. Celebrate and have a nap When starting the replica which now has all the master data rsynced over, I am getting the following error repeated over and over again: 2023-12-26 22:14:54 0 [ERROR] InnoDB: Page [page id: space=43077, page number=3] log sequence number 19989139444854 is in the future! Current system log sequence number 19246539202516. 2023-12-26 22:14:54 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. Then I get the following errors for many (but not all) tables: 2023-12-26 22:16:32 0 [ERROR] InnoDB: Expected tablespace id 3986547 but found 3986540 in the file ./ddx_practice_91804/alerts.ibd 2023-12-26 22:16:32 0 [Note] InnoDB: trying to read page [page id: space=3986547, page number=0] in the background in a non-existing or being-dropped tablespace The replica is totally useless, even though it is an exact copy, running on like hardware, same OS and similar major version of MariaDB. I've in the past used innodb_fast_shutdown = 0 on the master before final rsync, but I was told by MariaDB engineers that should not matter. I'm unclear why I'm seeing this corruption. 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.

2 2

Query Cache: Does a SELECT query tagged with SQL_NO_CACHE really touch the QC mutex?
by hellomaria-letmetrythisfirst＠mailinator.com 23 Dec '23

23 Dec '23

Hello, I found the query cache in MariaDB to be super useful and especially powerful when used in DEMAND mode. So I'd like to learn more about the performance characteristics. The documentation says that for the query cache, "the mutex is hit even for SQL_NO_CACHE": https://mariadb.com/kb/en/mariadb-memory-allocation/#query-cache Is there some more information about this somewhere? Why would a SELECT query that uses this directive dabble with the mutex at all?

2 3

Scheduled jobs recommendations
by ngtech1ltd＠gmail.com 19 Dec '23

19 Dec '23

Hey Everyone, I am currently using MariaDB 10.5.x from almalinux 9.3 and am testing latest 10.11 on Debian 12. I recently encountered an issue on 10.5 which probably didn’t run the stored procedure it should have. I have verified that the DB is configured properly ie: SET GLOBAL event_scheduler = ON; And also in the cnf files is default to ON and after a restart of the service the scheduler is on. I want to create a way to debug the stored procedure and the event scheduler. When I program a software I can log messages into somewhere but I don’t know how to do that in MariaDB and I would like to get a recommendation on how to do that this kind of logging in the when the even is being triggered and also after the call to the stored procedure ends. With this I can start to see if the event is being triggered and when. I am using it to cleanup a table and only leave the last 2 hours of data but it won’t run for at-least couple month now so I am calling the stored procedure from a cronjob. Thanks for any advice, Eliezer

2 1

Some questions restarting mariadb and importing the dumped databases
by Jogchum Reitsma 13 Dec '23

13 Dec '23

Hi all, On 3th of januari I posted the following topic, on the previous list address, maria-discuss(a)lists.launchpad.net, and gave it a reminder on the 19th of januari. I did not get an answer yet, maybe also because the list address changed in the mean time. So I take the liberty to pose the question again here, hoping this time someone is able to answer the the questions asked. Would be much appreciated! (I didn't mention it in the OP, but I've read https://mariadb.com/kb/en/mariadb-dump/, which does not seem to answer the questions) regards, Jogchum Hi, 12th of October I started the topic" Maria-db refuses to start". With the help offered in the conversation following I could access my data by manually starting an older version of Mariadb. This was on the previous list address, maria-discuss(a)lists.launchpad.net, so I then dumped my tables with mysqldump, one by one, successfully. I also dumped the mysql table. Final advice was to purge all reminiscences of the older versions, and make a fresh start by installing the version of my OS (OpenSuse Tumbleweed). In that new environment, import the dumped data. A few questions remain: - should I, after the install process of the OS version (at the moment 10.10.2-1.1) take further actions to get a fully functioning system? - should I import the dumped "mysql" table? - if yes, should I do that before or after importing the user data? Or doesn't that matter? Again, thanks for your answers! kind regards, Jogchum

2 2