I'm working with a MariaDB database where I have a table with two columns: id and values, where values contains JSON arrays. Here is a simplified example of the data: | id | values | |----|-------------| | 1 | "[1, 2, 3]" | | 1 | "" | | 2 | "" | I want to group the rows by id and concatenate the JSON arrays in the values column into a single array, like this: | id | values | |----|---------------| | 1 | "[1, 2, 3, 5]"| | 2 | "" | I tried using JSON_ARRAYAGG but it creates an array of arrays, and I can't figure out how to merge the arrays into one. How can I achieve this in MariaDB?

SELECT id, JSON_ARRAYAGG(values)
  FROM REC
GROUP BY id

Bonus question: How to output only unique values?

I have a question, and I've found one similar addressed, which I was going to respond to with my own questions (https://dba.stackexchange.com/questions/335192/live-database-migration-mariadb-10-5-to-mysql-8-0) , however, as that post/question is over a year old, I thought it may be better for me to create a new question. My Situation: I have a Web server (Apache) hosted by a 3rd party. The server is currently running MariaDB 10.5. On this server we have several sites, running on the last version or two of WordPress, and sites running Drupal 8, 9, and 10. Thus far, we've had no issues. However, we want to begin development of a couple projects on the Drupal 11 platform. When attempting to install D11, we're told that it requires MariaDB 10.6. I've made contact with our hosting company, and they've said that while they won't be upgrading our current server, they are willing to migrate us to another server, and we've been given the option to move to a server running MariaDB 10.6, or a server running MySQL 8. Being 100% honest, I know how to create the databases and from there, I've just let WordPress or Drupal do what they need to do. I've had no reasons to delve deeper into the Databases (Though this is an area that I'd like to learn more about). But for this situation, I'm not sure what is the better option to choose. Of course, objective Number One, would be to not break any of the currently running websites. I **presume** that migrating from the MariaDB 10.5 server to a MariaDB 10.6 server would be a "clean" move, but admittedly, I'm not positive of that. I'm also not sure what (if any) issues would be caused (or oppositely, benefits would be gained) migrating a MariaDB 10.5 website to a MySQL 8 server. I come to this forum, seeking your wisdom and direction. Thank you.

I search through a tag_map as SELECT ArticleID,COUNT(*) AS C FROM WordMap WHERE WordID IN( SELECT WordID FROM Words WHERE Word IN ('word1', 'word2') ) GROUP BY ArticleID ORDER BY C DESC I want to get article ids in which all words (here word1 and word2) appear first. The above query returns in order of the number (e.g., if word1 appears 100 times). NOTE: WordMap table is huge, and this is the reason I went for sub-query rather than JOIN.

We upgraded our MariaDB server from 10.2 to 10.5.23 and have found a significant CPU spike after this and almost most of the queries landing in the slow query logs. On investigation, we found that queries that were using the indexes on 10.2 were not getting used in 10.5 . Ive read a lot of material today where it was told that it may have been using the right indexes in 10.2 but 10.5 might NOT be using the same and hence the issue, which I fail to understand as its a straight forward index. For e.g. this is the query with explain on 10.2

MariaDB [client_db_17843]> explain SELECT p0_.ID AS ID0, c1_.Name AS Name1, c1_.Surname AS Surname2, c1_.CompanyName AS CompanyName3, c1_.MainContact AS MainContact4, c1_.TableType AS TableType5, p0_.ParentPropertyID AS ParentPropertyID6, p0_.AddressLine1 AS AddressLine17, p0_.AddressLine2 AS AddressLine28, p0_.Postcode AS Postcode9, c2_.EmailAddress AS EmailAddress10, c3_.TelephoneNumber AS TelephoneNumber11, c3_.CountryCode AS CountryCode12, c4_.TelephoneNumber AS TelephoneNumber13, c4_.CountryCode AS CountryCode14, c5_.TelephoneNumber AS TelephoneNumber15, c5_.CountryCode AS CountryCode16, s6_.Description AS Description17 FROM Properties p0_ INNER JOIN Contacts c1_ ON (c1_.TableType = 2 AND c1_.TablePKID = p0_.ID AND c1_.Deleted = 0) LEFT JOIN ContactsTelephones c3_ ON (c3_.ContactID = c1_.ID AND c3_.Deleted = 0 AND c3_.Settings_TypesOfTelephoneNumberID = 2) LEFT JOIN ContactsTelephones c4_ ON (c4_.ContactID = c1_.ID AND c4_.Deleted = 0 AND c4_.Settings_TypesOfTelephoneNumberID = 1) LEFT JOIN ContactsTelephones c5_ ON (c5_.ContactID = c1_.ID AND c5_.Deleted = 0 AND c5_.Settings_TypesOfTelephoneNumberID  1 AND c5_.Settings_TypesOfTelephoneNumberID  2) LEFT JOIN ContactsEmails c2_ ON (c2_.ContactID = c1_.ID AND c2_.Deleted = 0) LEFT JOIN Settings_Titles s6_ ON (s6_.ID = c1_.Settings_TitleID) WHERE (c1_.MainContact = 1 OR c1_.MainContact = 0) AND p0_.Deleted = 0 GROUP BY p0_.ID ORDER BY p0_.ID DESC LIMIT 10 OFFSET 0;
+------+-------------+-------+--------+---------------------------------------------------------------------+----------------------+---------+--------------------------------------+------+-------------+
| id   | select_type | table | type   | possible_keys                                                       | key                  | key_len | ref                                  | rows | Extra       |
+------+-------------+-------+--------+---------------------------------------------------------------------+----------------------+---------+--------------------------------------+------+-------------+
|    1 | SIMPLE      | c1_   | index  | IX_Contacts_idx                                                     | IX_Contacts_idx      | 10      | NULL                                 |   10 | Using where |
|    1 | SIMPLE      | p0_   | eq_ref | PRIMARY                                                             | PRIMARY              | 4       | client_db_17843.c1_.TablePKID        |    1 | Using where |
|    1 | SIMPLE      | c3_   | ref    | IDX_5FD82FF8CDD4564D,IDX_5FD82FF8A9B070B8,ix_Contactstelephones_idx | IDX_5FD82FF8CDD4564D | 5       | client_db_17843.c1_.ID               |    1 | Using where |
|    1 | SIMPLE      | c4_   | ref    | IDX_5FD82FF8CDD4564D,IDX_5FD82FF8A9B070B8,ix_Contactstelephones_idx | IDX_5FD82FF8CDD4564D | 5       | client_db_17843.c1_.ID               |    1 | Using where |
|    1 | SIMPLE      | c5_   | ref    | IDX_5FD82FF8CDD4564D,IDX_5FD82FF8A9B070B8,ix_Contactstelephones_idx | IDX_5FD82FF8CDD4564D | 5       | client_db_17843.c1_.ID               |    1 | Using where |
|    1 | SIMPLE      | c2_   | ref    | IDX_1EC6F1D5CDD4564D,ix_Contactsemails_idx                          | IDX_1EC6F1D5CDD4564D | 5       | client_db_17843.c1_.ID               |    1 | Using where |
|    1 | SIMPLE      | s6_   | eq_ref | PRIMARY                                                             | PRIMARY              | 4       | client_db_17843.c1_.Settings_TitleID |    1 | Using where |
+------+-------------+-------+--------+---------------------------------------------------------------------+----------------------+---------+--------------------------------------+------+-------------+
7 rows in set (0.00 sec)

The same on 10.5 does this

MariaDB [client_db_17843]> explain SELECT p0_.ID AS ID0, c1_.Name AS Name1, c1_.Surname AS Surname2, c1_.CompanyName AS CompanyName3, c1_.MainContact AS MainContact4, c1_.TableType AS TableType5, p0_.ParentPropertyID AS ParentPropertyID6, p0_.AddressLine1 AS AddressLine17, p0_.AddressLine2 AS AddressLine28, p0_.Postcode AS Postcode9, c2_.EmailAddress AS EmailAddress10, c3_.TelephoneNumber AS TelephoneNumber11, c3_.CountryCode AS CountryCode12, c4_.TelephoneNumber AS TelephoneNumber13, c4_.CountryCode AS CountryCode14, c5_.TelephoneNumber AS TelephoneNumber15, c5_.CountryCode AS CountryCode16, s6_.Description AS Description17 FROM Properties p0_ INNER JOIN Contacts c1_ ON (c1_.TableType = 2 AND c1_.TablePKID = p0_.ID AND c1_.Deleted = 0) LEFT JOIN ContactsTelephones c3_ ON (c3_.ContactID = c1_.ID AND c3_.Deleted = 0 AND c3_.Settings_TypesOfTelephoneNumberID = 2) LEFT JOIN ContactsTelephones c4_ ON (c4_.ContactID = c1_.ID AND c4_.Deleted = 0 AND c4_.Settings_TypesOfTelephoneNumberID = 1) LEFT JOIN ContactsTelephones c5_ ON (c5_.ContactID = c1_.ID AND c5_.Deleted = 0 AND c5_.Settings_TypesOfTelephoneNumberID  1 AND c5_.Settings_TypesOfTelephoneNumberID  2) LEFT JOIN ContactsEmails c2_ ON (c2_.ContactID = c1_.ID AND c2_.Deleted = 0) LEFT JOIN Settings_Titles s6_ ON (s6_.ID = c1_.Settings_TitleID) WHERE (c1_.MainContact = 1 OR c1_.MainContact = 0) AND p0_.Deleted = 0 GROUP BY p0_.ID ORDER BY p0_.ID DESC LIMIT 10 OFFSET 0; 
+------+-------------+-------+------------+---------------------------------------------------------------------+-------------------------------------------+---------+-------------------------------+--------+-------------------------------------------------+
| id   | select_type | table | type       | possible_keys                                                       | key                                       | key_len | ref                           | rows   | Extra                                           |
+------+-------------+-------+------------+---------------------------------------------------------------------+-------------------------------------------+---------+-------------------------------+--------+-------------------------------------------------+
|    1 | SIMPLE      | c1_   | ALL        | IX_Contacts_idx                                                     | NULL                                      | NULL    | NULL                          | 159293 | Using where; Using temporary; Using filesort    |
|    1 | SIMPLE      | p0_   | eq_ref     | PRIMARY                                                             | PRIMARY                                   | 4       | client_db_17843.c1_.TablePKID | 1      | Using where                                     |
|    1 | SIMPLE      | c3_   | ref        | IDX_5FD82FF8CDD4564D,IDX_5FD82FF8A9B070B8,ix_Contactstelephones_idx | IDX_5FD82FF8CDD4564D                      | 5       | client_db_17843.c1_.ID        | 1      | Using where                                     |
|    1 | SIMPLE      | c4_   | ref        | IDX_5FD82FF8CDD4564D,IDX_5FD82FF8A9B070B8,ix_Contactstelephones_idx | IDX_5FD82FF8CDD4564D                      | 5       | client_db_17843.c1_.ID        | 1      | Using where                                     |
|    1 | SIMPLE      | c5_   | ref|filter | IDX_5FD82FF8CDD4564D,IDX_5FD82FF8A9B070B8,ix_Contactstelephones_idx | IDX_5FD82FF8CDD4564D|IDX_5FD82FF8A9B070B8 | 5|5     | client_db_17843.c1_.ID        | 1 (0%) | Using where; Using rowid filter                 |
|    1 | SIMPLE      | c2_   | ref        | IDX_1EC6F1D5CDD4564D,ix_Contactsemails_idx                          | IDX_1EC6F1D5CDD4564D                      | 5       | client_db_17843.c1_.ID        | 1      | Using where                                     |
|    1 | SIMPLE      | s6_   | ALL        | PRIMARY                                                             | NULL                                      | NULL    | NULL                          | 11     | Using where; Using join buffer (flat, BNL join) |
+------+-------------+-------+------------+---------------------------------------------------------------------+-------------------------------------------+---------+-------------------------------+--------+-------------------------------------------------+
7 rows in set (0.001 sec)

Its doing a full table scan on the Contacts table even though the index that it suggested IX_Contacts_idx does have the right columns that are in the ON condition in the query. We have read through a few bits of documentation but unsure if there are any mariadb optimizer specific hints that we are missing on 10.5.x. Any pointers will be greatly appreciated as we upgraded it and its been very bad post the upgrade. Operation System: Rocky Linux 8.8 MariaDB Version: 10.5.23 CPU: 52 core (WE have increased this from 20 core this morning since the box was getting pegged a lot and had to increase to sustain the load) Memory: 64GB All tables are INNODB innodb_params:

MariaDB [client_db_17843]> show variables like 'innodb_buffer%';
+-------------------------------------+----------------+
| Variable_name                       | Value          |
+-------------------------------------+----------------+
| innodb_buffer_pool_chunk_size       | 134217728      |
| innodb_buffer_pool_dump_at_shutdown | ON             |
| innodb_buffer_pool_dump_now         | OFF            |
| innodb_buffer_pool_dump_pct         | 25             |
| innodb_buffer_pool_filename         | ib_buffer_pool |
| innodb_buffer_pool_instances        | 1              |
| innodb_buffer_pool_load_abort       | OFF            |
| innodb_buffer_pool_load_at_startup  | ON             |
| innodb_buffer_pool_load_now         | OFF            |
| innodb_buffer_pool_size             | 19327352832    |
+-------------------------------------+----------------+
10 rows in set (0.000 sec)

Optimizer trace for the above is: https://pastebin.com/NtJHf9nw PS: This is just one query that is slow, Overall, the performance has gone down so bad that we have more than 20x slow queries than what we had in mariadb 10.2. I just got the above as an example for investigation. Thanks Raja

I am using Kafka and Debezium to connect to a MariaDB I have a problem where in the event the MariaDB loses power and shutsdown abruptly, on restart Debezium is no longer able to connect I have this error in particular

[2023-12-06 13:26:05,800] ERROR [192.168.108.1|task-0] Error during binlog processing. Last offset stored = null, binlog reader near position = mariadb-bin.000006/53938 (io.debezium.connector.mysql.MySqlStreamingChangeEventSource:1161)

io.debezium.DebeziumException: Client requested master to start replication from impossible position; the first event 'mariadb-bin.000006' at 53938, the last event read from 'mariadb-bin.000006' at 4, the last byte read from 'mariadb-bin.000006' at 4. Error code: 1236; SQLSTATE: HY000.

And on the mariadb side i have this

+--------------------+-----------+
| Log_name           | File_size |
+--------------------+-----------+
| mariadb-bin.000001 |       330 |
| mariadb-bin.000002 |       330 |
| mariadb-bin.000003 |     67494 |
| mariadb-bin.000004 |     69007 |
| mariadb-bin.000005 |    126922 |
| mariadb-bin.000006 |     45056 |
| mariadb-bin.000007 |    103304 |
+--------------------+-----------+
7 rows in set (0.001 sec)

MariaDB [(none)]> show master status;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000007 |   103304 |              |                  |
+--------------------+----------+--------------+------------------+
1 row in set (0.000 sec)

I have tried resetting offsets on Kafka side of things but I get the exact same error without fail, does anyone know why exactly there is a problem and how to resolve things? All help appreciated thanks so much!

I can't find or think of a solution when ever i encounter db replication errors on affected source and repositioning the GTID in the replica. What i do is retrieve from (four) masters gtid postion (show master status) then copy it to the replica server. In replica server. set global gtid_slave_pos="1-10-1111111,2-20-2222222,3-30-3333333,4-40-444444" Is there a way to reposition the gtid_slave_posonly the affected source and will not cause any sync issues on other source that has no errors. I'm using MariaDB 10.5 for master and replica.

I have database table with a tens of millions of records. For some reason the auto increment id column is a signed int and I tried to change it to an unsigned int. Goes without saying but I checked there are no negative values in that column. I tried to use the following statement:

ALTER TABLE table 
MODIFY COLUMN id INT UNSIGNED AUTO_INCREMENT, 
ALGORITHM INSTANT, 
LOCK = NONE;

which was unsuccessful due to it requiring the COPY algorithm

ALGORITHM=INSTANT is not supported. Reason: Cannot change column type. Try 
ALGORITHM=COPY

Since the table is quite large (~15gb data + 15gb indexes) the COPY algorithm would take a long time during which the table would lock. I would assume, that only meta data would be modified, since the storage should not change at all. Both have the same amount of bytes (4) and for positive values the bit-representation should be identical. Everything should be identical. What's the reason why COPY is the only supported algorithm? Is there any way to achieve this without copying the whole table?

I have a InnoDB table with the following columns: BIGINT -> 8 bytes BIGINT -> 8 bytes ENUM(0,1) -> 1 byte MEDIUMINT -> 3 bytes INT -> 4 bytes = 24 bytes per row It contains 10454004 rows (based on COUNT(*)), so I calculate the Data size as **250MB**. This table's PRIMARY key is BIGINT, BIGINT, ENUM. And has an INDEX on the INT. Based on information_schema, DATA_LENGTH = **530.8MiB** INDEX_LENGTH = 272.0MiB DATA_FREE = 6.0MiB = 808.8MiB = **848 MB** Also, AVG_ROW_LENGTH = 87 instead of 24 And then I look at the actual .ibd file size, which is reported as: 1451229184 bytes = **1451.23 MB** I understand there is fragmentation and sparse files in question (the records on this table are regularly expired, but never had a bigger retention time than currently is). But I'm not understanding why do I see 3 different sizes, with such big gap each. Goes from 250MB of real calculable data, to 530MiB of Data. And DATA_FREE is only 6MiB. And 848 MB reported by information_schema (which per my understanding includes "free space" as well), much lower than the actual .ibd file. **From Comment** CREATE TABLE mytable ( uid bigint(18) unsigned NOT NULL, tid bigint(18) unsigned NOT NULL, fst enum('0','1') COLLATE utf8mb4_unicode_ci NOT NULL, sn mediumint(8) unsigned NOT NULL DEFAULT 1, ls int(10) unsigned NOT NULL, PRIMARY KEY (uid,tid,fst) USING BTREE, KEY ls (ls) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci **What am I missing or not considering?**

I have a linux server running mariaDB-5.5; the tables are all (I think) innoDB tables and the data are stored on a raw partition; actually on two raw partitions because some years ago at the last hardware upgrade, we added a second one for growth capacity. I've just checked and right now, the "data length" + "index length" of my tables comes to about 95GB. I'm about to migrate to new storage and servers -- and OS, so will be using mariaDB-10.5 (or I may go for 11.4 instead of the OS-supplied version). As far as I can see from the docs, this should not have any major issues, but I'd appreciate expert/exsperienced thoughts on some points, which are interconnected: 1) **Raw partitions**: does it make any real difference if I continue with multiple raw filesystems vs making one big one? 2) **Is a raw partition still sensible?** This was set up by my predecessor, but reading around the docs, I'm not entirely sure that this is likely to give an improvement in performance vs the "one file per table" config. Any thoughts? How to do speed tests that reflect the usage in a production environment is not really clear to meL: I don't have the capacity to create a dev clone of the live system. 3) **mysqldump vs dd**. Last time I did this, I just used dd to literally byte-wise copy the old raw partition to the new one. That's why we have two partitions because this of course precluded resizing it. This is partly because mysqldump produces a very large file, and partly because I'm slightly scared that there will end up with a foreign key deadlock or something silly like that if I go that route. On the other hand, using dd requires me to create raw partitions on the new machine, exactly duplicating the number and size on the old one (hence question 1) which is obviously somewhat restrictive. And I guess while I'm here, any nasty gotchas that I haven't foreseen that I should be aware of? I will read on up the percona toolkit options for this as well, but haven't got that far yet!

I have installed MariaDB via brew and each time I restart my computer I need to start it manually by brew services start mariadb@10.5 Also I cannot find mariadb listed in the "Login Items" in Settings > General How do I make mariadb appear in the "Login Items"? Thank you in advance.

Today, suddenly our mysql database server got down. Few minutes after restarting the server went down again, and again. To see what is happening, we temporarily put our application in maintenance mode and found that the database didn't go down anymore. This helped me to find out what was happening; Every

or

on one specific table caused lots of

queries (on that same table) to "Waiting for table metadata lock". As a result of that many open connections already appear within a few seconds and finally the server is crashing. I couldn't understand why a simple

app.notes SET user_id=5 WHERE note_id=1

query took so long and even after 10 minutes waiting wasn't finished. The

PROCESSLIST

state on that query was still Executing. Again, I restarted the server and after some research, I found that there is one metadata lock on that specific table

MariaDB [(none)]> SELECT * FROM information_schema.METADATA_LOCK_INFO;
+-----------+------------+---------------+---------------------+--------------+------------+
| THREAD_ID | LOCK_MODE  | LOCK_DURATION | LOCK_TYPE           | TABLE_SCHEMA | TABLE_NAME |
+-----------+------------+---------------+---------------------+--------------+------------+
|         0 | MDL_SHARED | NULL          | Table metadata lock | app          | notes      |
+-----------+------------+---------------+---------------------+--------------+------------+
1 row in set (0.000 sec)

But since that

is 0, I can't find anything how to delete the lock. So where I am at the moment; the server is rebooted, MySQL is started, no query has been executed yet on that specific table and that one metalock on app.notes is still there. All these have empty results: Transaction section in

ENGINE innodb STATUS;

* FROM INNODB_LOCK_WAITS;

* FROM INNODB_LOCKS;

* FROM INNODB_TRX;

FULL PROCESSLIST;

I've already tried to

TABLE

but that also results in "Waiting for table metadata lock". What can I do or try to make the lock go away??

Using MariaDB 10.5.12 on CentOS 7 If it makes any difference, my "optimizer_use_condition_selectivity" = 1 If I run: EXPLAIN SELECT COUNT(*) FROM ips WHERE ip="1.2.3.4" This query uses the index on the ip column (simple index). However, if I run (simplest example query I could get): EXPLAIN SELECT srl.id, (SELECT COUNT(*) FROM ips WHERE ip=srl.ip) as ipcount FROM srl LIMIT 10 The subquery on the ips table doesn't have ip as possible_keys, it uses the time index (which isn't even used in the query!), and does a table scan (and this is a huge table). If I put FORCE INDEX(ip), the EXPLAIN says it uses the ip key, but it still does a table scan. If I hardcode an IP, like: EXPLAIN SELECT srl.id, (SELECT COUNT(*) FROM ips WHERE ip="1.2.3.4") as ipcount FROM srl LIMIT 10 It uses the ip key as intended. **What is preventing the subquery from using the index as supposed, in the ip=srl.ip example?** ANALYZE FORMAT=JSON: { "query_block": { "select_id": 1, "r_loops": 1, "r_total_time_ms": 19537.7025, "table": { "table_name": "srl", "access_type": "ALL", "r_loops": 1, "rows": 92181, "r_rows": 10, "r_table_time_ms": 0.055588922, "r_other_time_ms": 0.116198584, "filtered": 100, "r_filtered": 100 }, "subqueries": [ { "expression_cache": { "r_loops": 10, "r_hit_ratio": 30, "query_block": { "select_id": 2, "r_loops": 7, "r_total_time_ms": 19537.40246, "table": { "table_name": "ips", "access_type": "index", "key": "time", "key_length": "4", "used_key_parts": ["time"], "r_loops": 7, "rows": 4948857, "r_rows": 5949193, "r_table_time_ms": 12379.15752, "r_other_time_ms": 7158.182676, "filtered": 100, "r_filtered": 1.656887e-4, "attached_condition": "convert(ips.ip using utf8mb4) = srl.ip", "using_index": true } } } } ] } }

I am currently unable to restart [**what I thought was**] a previously working version of mariadb. Rocky Linux 8.6 server crashed during yum update and became unbootable. I installed Rocky Linux 9.3 and reinstalled mariadb and mariadb-server. Mariadb now fails to start on previous data directory with: % systemctl start mariadb

2024-03-29 15:24:37 0 [Note] Starting MariaDB 10.5.22-MariaDB source revision 7e650253dc488debcb0898ebe6d385bf6dfa3656 as process 1971547
2024-03-29 15:24:37 0 [Note] InnoDB: Uses event mutexes
2024-03-29 15:24:37 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2024-03-29 15:24:37 0 [Note] InnoDB: Number of pools: 1
2024-03-29 15:24:37 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2024-03-29 15:24:37 0 [Note] InnoDB: Using Linux native AIO
2024-03-29 15:24:37 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2024-03-29 15:24:37 0 [Note] InnoDB: Completed initialization of buffer pool
2024-03-29 15:24:37 0 [ERROR] InnoDB: MySQL-8.0 tablespace in ./ibdata1
2024-03-29 15:24:37 0 [ERROR] InnoDB: Restart in MySQL for migration/recovery.
2024-03-29 15:24:37 0 [ERROR] InnoDB: Plugin initialization aborted with error Unsupported
2024-03-29 15:24:37 0 [Note] InnoDB: Starting shutdown...
2024-03-29 15:24:37 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2024-03-29 15:24:37 0 [Note] Plugin 'FEEDBACK' is disabled.
2024-03-29 15:24:37 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2024-03-29 15:24:37 0 [ERROR] Aborting

I have attempted innodb_force_recovery from 1 to 6, to no avail. What would you recommend? Thank you.

I have problems with my Drupal 10/MariaDB 10.5/PHP 8.1 website when they are 20 users simultaniously. The website goes down and the response time is really big (up to 30seconds sometimes) because php-fpm process falls (see locust tests). I've modified nginx config, i see improuvment but still, I can't go more than 30 users without the website becoming KO. Do you have any advice ? MariaDB is the only thing that's common between several of my project that are quite slow when a few users are using the website... alter_algorithm DEFAULT analyze_sample_percentage 100.000000 aria_block_size 8192 aria_checkpoint_interval 30 aria_checkpoint_log_activity 1048576 aria_encrypt_tables OFF aria_force_start_after_recovery_failures 0 aria_group_commit none aria_group_commit_interval 0 aria_log_dir_path /var/lib/mysql/ aria_log_file_size 1073741824 aria_log_purge_type immediate aria_max_sort_file_size 9223372036853727232 aria_page_checksum ON aria_pagecache_age_threshold 300 aria_pagecache_buffer_size 134217728 aria_pagecache_division_limit 100 aria_pagecache_file_hash_size 512 aria_recover_options BACKUP,QUICK aria_repair_threads 1 aria_sort_buffer_size 268434432 aria_stats_method nulls_unequal aria_sync_log_dir NEWFILE aria_used_for_temp_tables ON auto_increment_increment 1 auto_increment_offset 1 autocommit ON automatic_sp_privileges ON back_log 2000 basedir /usr big_tables OFF bind_address 0.0.0.0 binlog_annotate_row_events ON binlog_cache_size 32768 binlog_checksum CRC32 binlog_commit_wait_count 0 binlog_commit_wait_usec 100000 binlog_direct_non_transactional_updates OFF binlog_file_cache_size 16384 binlog_format MIXED binlog_optimize_thread_scheduling ON binlog_row_image FULL binlog_row_metadata NO_LOG binlog_stmt_cache_size 32768 bulk_insert_buffer_size 8388608 character_set_client utf8mb4 character_set_connection utf8mb4 character_set_database utf8mb4 character_set_filesystem binary character_set_results utf8mb4 character_set_server utf8mb4 character_set_system utf8 character_sets_dir /usr/share/mysql/charsets/ check_constraint_checks ON collation_connection utf8mb4_general_ci collation_database utf8mb4_general_ci collation_server utf8mb4_general_ci column_compression_threshold 100 column_compression_zlib_level 6 column_compression_zlib_strategy DEFAULT_STRATEGY column_compression_zlib_wrap OFF completion_type NO_CHAIN concurrent_insert AUTO connect_timeout 10 core_file OFF datadir /var/lib/mysql/ date_format %Y-%m-%d datetime_format %Y-%m-%d %H:%i:%s deadlock_search_depth_long 15 deadlock_search_depth_short 4 deadlock_timeout_long 50000000 deadlock_timeout_short 10000 debug_no_thread_alarm OFF default_password_lifetime 0 default_regex_flags default_storage_engine InnoDB default_tmp_storage_engine default_week_format 0 delay_key_write ON delayed_insert_limit 100 delayed_insert_timeout 300 delayed_queue_size 1000 disconnect_on_expired_password OFF div_precision_increment 4 encrypt_binlog OFF encrypt_tmp_disk_tables OFF encrypt_tmp_files OFF enforce_storage_engine eq_range_index_dive_limit 200 event_scheduler OFF expensive_subquery_limit 100 expire_logs_days 10 explicit_defaults_for_timestamp OFF extra_max_connections 1 extra_port 0 flush OFF flush_time 0 foreign_key_checks ON ft_boolean_syntax + -><()~*:""&| ft_max_word_len 84 ft_min_word_len 4 ft_query_expansion_limit 20 ft_stopword_file (built-in) general_log OFF general_log_file /var/log/mysql/mysql.log group_concat_max_len 1048576 gtid_binlog_pos gtid_binlog_state gtid_cleanup_batch_size 64 gtid_current_pos gtid_domain_id 0 gtid_ignore_duplicates OFF gtid_pos_auto_engines gtid_slave_pos gtid_strict_mode OFF have_compress YES have_crypt YES have_dynamic_loading YES have_geometry YES have_openssl YES have_profiling YES have_query_cache YES have_rtree_keys YES have_ssl DISABLED have_symlink YES histogram_size 254 histogram_type DOUBLE_PREC_HB host_cache_size 1103 hostname vaneau22 idle_readonly_transaction_timeout 0 idle_transaction_timeout 0 idle_write_transaction_timeout 0 ignore_builtin_innodb OFF ignore_db_dirs in_predicate_conversion_threshold 1000 init_connect init_file init_slave innodb_adaptive_flushing ON innodb_adaptive_flushing_lwm 10.000000 innodb_adaptive_hash_index OFF innodb_adaptive_hash_index_parts 8 innodb_adaptive_max_sleep_delay 0 innodb_autoextend_increment 64 innodb_autoinc_lock_mode 1 innodb_background_scrub_data_check_interval 0 innodb_background_scrub_data_compressed OFF innodb_background_scrub_data_interval 0 innodb_background_scrub_data_uncompressed OFF innodb_buf_dump_status_frequency 0 innodb_buffer_pool_chunk_size 134217728 innodb_buffer_pool_dump_at_shutdown ON innodb_buffer_pool_dump_now OFF innodb_buffer_pool_dump_pct 25 innodb_buffer_pool_filename ib_buffer_pool innodb_buffer_pool_instances 1 innodb_buffer_pool_load_abort OFF innodb_buffer_pool_load_at_startup ON innodb_buffer_pool_load_now OFF innodb_buffer_pool_size 6442450944 innodb_change_buffer_max_size 25 innodb_change_buffering none innodb_checksum_algorithm full_crc32 innodb_cmp_per_index_enabled OFF innodb_commit_concurrency 0 innodb_compression_algorithm zlib innodb_compression_default OFF innodb_compression_failure_threshold_pct 5 innodb_compression_level 6 innodb_compression_pad_pct_max 50 innodb_concurrency_tickets 0 innodb_data_file_path ibdata1:12M:autoextend innodb_data_home_dir innodb_deadlock_detect ON innodb_default_encryption_key_id 1 innodb_default_row_format dynamic innodb_defragment OFF innodb_defragment_fill_factor 0.900000 innodb_defragment_fill_factor_n_recs 20 innodb_defragment_frequency 40 innodb_defragment_n_pages 7 innodb_defragment_stats_accuracy 0 innodb_disable_sort_file_cache OFF innodb_doublewrite ON innodb_encrypt_log OFF innodb_encrypt_tables OFF innodb_encrypt_temporary_tables OFF innodb_encryption_rotate_key_age 1 innodb_encryption_rotation_iops 100 innodb_encryption_threads 0 innodb_fast_shutdown 1 innodb_fatal_semaphore_wait_threshold 600 innodb_file_format innodb_file_per_table ON innodb_fill_factor 100 innodb_flush_log_at_timeout 1 innodb_flush_log_at_trx_commit 1 innodb_flush_method fsync innodb_flush_neighbors 1 innodb_flush_sync ON innodb_flushing_avg_loops 30 innodb_force_load_corrupted OFF innodb_force_primary_key OFF innodb_force_recovery 0 innodb_ft_aux_table innodb_ft_cache_size 8000000 innodb_ft_enable_diag_print OFF innodb_ft_enable_stopword ON innodb_ft_max_token_size 84 innodb_ft_min_token_size 3 innodb_ft_num_word_optimize 2000 innodb_ft_result_cache_limit 2000000000 innodb_ft_server_stopword_table innodb_ft_sort_pll_degree 2 innodb_ft_total_cache_size 640000000 innodb_ft_user_stopword_table innodb_immediate_scrub_data_uncompressed OFF innodb_instant_alter_column_allowed add_drop_reorder innodb_io_capacity 200 innodb_io_capacity_max 2000 innodb_large_prefix innodb_lock_schedule_algorithm fcfs innodb_lock_wait_timeout 50 innodb_log_buffer_size 16777216 innodb_log_checksums ON innodb_log_compressed_pages ON innodb_log_file_size 268435456 innodb_log_files_in_group 1 innodb_log_group_home_dir ./ innodb_log_optimize_ddl OFF innodb_log_write_ahead_size 8192 innodb_lru_flush_size 32 innodb_lru_scan_depth 1536 innodb_max_dirty_pages_pct 90.000000 innodb_max_dirty_pages_pct_lwm 0.000000 innodb_max_purge_lag 0 innodb_max_purge_lag_delay 0 innodb_max_purge_lag_wait 4294967295 innodb_max_undo_log_size 10485760 innodb_monitor_disable innodb_monitor_enable innodb_monitor_reset innodb_monitor_reset_all innodb_old_blocks_pct 37 innodb_old_blocks_time 1000 innodb_online_alter_log_max_size 134217728 innodb_open_files 2000 innodb_optimize_fulltext_only OFF innodb_page_cleaners 1 innodb_page_size 16384 innodb_prefix_index_cluster_optimization OFF innodb_print_all_deadlocks OFF innodb_purge_batch_size 300 innodb_purge_rseg_truncate_frequency 128 innodb_purge_threads 4 innodb_random_read_ahead OFF innodb_read_ahead_threshold 56 innodb_read_io_threads 4 innodb_read_only OFF innodb_replication_delay 0 innodb_rollback_on_timeout OFF innodb_scrub_log OFF innodb_scrub_log_speed 256 innodb_sort_buffer_size 1048576 innodb_spin_wait_delay 4 innodb_stats_auto_recalc ON innodb_stats_include_delete_marked OFF innodb_stats_method nulls_equal innodb_stats_modified_counter 0 innodb_stats_on_metadata OFF innodb_stats_persistent ON innodb_stats_persistent_sample_pages 20 innodb_stats_traditional ON innodb_stats_transient_sample_pages 8 innodb_status_output OFF innodb_status_output_locks OFF innodb_strict_mode ON innodb_sync_array_size 1 innodb_sync_spin_loops 30 innodb_table_locks ON innodb_temp_data_file_path ibtmp1:12M:autoextend innodb_thread_concurrency 0 innodb_thread_sleep_delay 0 innodb_tmpdir innodb_undo_directory ./ innodb_undo_log_truncate OFF innodb_undo_logs 128 innodb_undo_tablespaces 0 innodb_use_atomic_writes ON innodb_use_native_aio ON innodb_version 10.5.21 innodb_write_io_threads 4 interactive_timeout 28800 join_buffer_size 262144 join_buffer_space_limit 2097152 join_cache_level 2 keep_files_on_create OFF key_buffer_size 134217728 key_cache_age_threshold 300 key_cache_block_size 1024 key_cache_division_limit 100 key_cache_file_hash_size 512 key_cache_segments 0 large_files_support ON large_page_size 0 large_pages OFF lc_messages en_US lc_messages_dir /usr/share/mysql lc_time_names en_US license GPL local_infile ON lock_wait_timeout 86400 locked_in_memory OFF log_bin OFF log_bin_basename log_bin_compress OFF log_bin_compress_min_len 256 log_bin_index log_bin_trust_function_creators OFF log_disabled_statements sp log_error /var/log/mysql/mysql_error.log log_output FILE log_queries_not_using_indexes OFF log_slave_updates OFF log_slow_admin_statements ON log_slow_disabled_statements sp log_slow_filter admin,filesort,filesort_on_disk,filesort_priority_queue,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk log_slow_rate_limit 1 log_slow_slave_statements ON log_slow_verbosity log_tc_size 24576 log_warnings 2 long_query_time 10.000000 low_priority_updates OFF lower_case_file_system OFF lower_case_table_names 0 master_verify_checksum OFF max_allowed_packet 16777216 max_binlog_cache_size 18446744073709547520 max_binlog_size 1073741824 max_binlog_stmt_cache_size 18446744073709547520 max_connect_errors 100 max_connections 10000 max_delayed_threads 20 max_digest_length 1024 max_error_count 64 max_heap_table_size 16777216 max_insert_delayed_threads 20 max_join_size 18446744073709551615 max_length_for_sort_data 1024 max_password_errors 4294967295 max_prepared_stmt_count 16382 max_recursive_iterations 4294967295 max_relay_log_size 1073741824 max_rowid_filter_size 131072 max_seeks_for_key 4294967295 max_session_mem_used 9223372036854775807 max_sort_length 1024 max_sp_recursion_depth 0 max_statement_time 0.000000 max_tmp_tables 32 max_user_connections 0 max_write_lock_count 4294967295 metadata_locks_cache_size 1024 metadata_locks_hash_instances 8 min_examined_row_limit 0 mrr_buffer_size 262144 myisam_block_size 1024 myisam_data_pointer_size 6 myisam_max_sort_file_size 9223372036853727232 myisam_mmap_size 18446744073709551615 myisam_recover_options BACKUP,QUICK myisam_repair_threads 1 myisam_sort_buffer_size 134216704 myisam_stats_method NULLS_UNEQUAL myisam_use_mmap OFF mysql56_temporal_format ON net_buffer_length 16384 net_read_timeout 30 net_retry_count 10 net_write_timeout 60 old OFF old_alter_table DEFAULT old_mode old_passwords OFF open_files_limit 32768 optimizer_max_sel_arg_weight 32000 optimizer_prune_level 1 optimizer_search_depth 62 optimizer_selectivity_sampling_limit 100 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 optimizer_trace enabled=off optimizer_trace_max_mem_size 1048576 optimizer_use_condition_selectivity 4 performance_schema OFF performance_schema_accounts_size -1 performance_schema_digests_size -1 performance_schema_events_stages_history_long_size -1 performance_schema_events_stages_history_size -1 performance_schema_events_statements_history_long_size -1 performance_schema_events_statements_history_size -1 performance_schema_events_transactions_history_long_size -1 performance_schema_events_transactions_history_size -1 performance_schema_events_waits_history_long_size -1 performance_schema_events_waits_history_size -1 performance_schema_hosts_size -1 performance_schema_max_cond_classes 90 performance_schema_max_cond_instances -1 performance_schema_max_digest_length 1024 performance_schema_max_file_classes 80 performance_schema_max_file_handles 32768 performance_schema_max_file_instances -1 performance_schema_max_index_stat -1 performance_schema_max_memory_classes 320 performance_schema_max_metadata_locks -1 performance_schema_max_mutex_classes 210 performance_schema_max_mutex_instances -1 performance_schema_max_prepared_statements_instances -1 performance_schema_max_program_instances -1 performance_schema_max_rwlock_classes 50 performance_schema_max_rwlock_instances -1 performance_schema_max_socket_classes 10 performance_schema_max_socket_instances -1 performance_schema_max_sql_text_length 1024 performance_schema_max_stage_classes 160 performance_schema_max_statement_classes 222 performance_schema_max_statement_stack 10 performance_schema_max_table_handles -1 performance_schema_max_table_instances -1 performance_schema_max_table_lock_stat -1 performance_schema_max_thread_classes 50 performance_schema_max_thread_instances -1 performance_schema_session_connect_attrs_size -1 performance_schema_setup_actors_size -1 performance_schema_setup_objects_size -1 performance_schema_users_size -1 pid_file /run/mysqld/mysqld.pid plugin_dir /usr/lib/mysql/plugin/ plugin_maturity gamma port 3306 preload_buffer_size 32768 profiling OFF profiling_history_size 15 progress_report_time 5 protocol_version 10 proxy_protocol_networks query_alloc_block_size 16384 query_cache_limit 1048576 query_cache_min_res_unit 4096 query_cache_size 1048576 query_cache_strip_comments OFF query_cache_type OFF query_cache_wlock_invalidate OFF query_prealloc_size 24576 range_alloc_block_size 4096 read_binlog_speed_limit 0 read_buffer_size 131072 read_only OFF read_rnd_buffer_size 262144 relay_log relay_log_basename relay_log_index relay_log_info_file relay-log.info relay_log_purge ON relay_log_recovery OFF relay_log_space_limit 0 replicate_annotate_row_events ON replicate_do_db replicate_do_table replicate_events_marked_for_skip REPLICATE replicate_ignore_db replicate_ignore_table replicate_wild_do_table replicate_wild_ignore_table report_host report_password report_port 3306 report_user require_secure_transport OFF rowid_merge_buff_size 8388608 rpl_semi_sync_master_enabled OFF rpl_semi_sync_master_timeout 10000 rpl_semi_sync_master_trace_level 32 rpl_semi_sync_master_wait_no_slave ON rpl_semi_sync_master_wait_point AFTER_COMMIT rpl_semi_sync_slave_delay_master OFF rpl_semi_sync_slave_enabled OFF rpl_semi_sync_slave_kill_conn_timeout 5 rpl_semi_sync_slave_trace_level 32 secure_auth ON secure_file_priv secure_timestamp NO server_id 1 session_track_schema ON session_track_state_change OFF session_track_system_variables autocommit,character_set_client,character_set_connection,character_set_results,time_zone session_track_transaction_info OFF skip_external_locking ON skip_name_resolve OFF skip_networking OFF skip_show_database OFF slave_compressed_protocol OFF slave_ddl_exec_mode IDEMPOTENT slave_domain_parallel_threads 0 slave_exec_mode STRICT slave_load_tmpdir /tmp slave_max_allowed_packet 1073741824 slave_net_timeout 60 slave_parallel_max_queued 131072 slave_parallel_mode optimistic slave_parallel_threads 0 slave_parallel_workers 0 slave_run_triggers_for_rbr NO slave_skip_errors OFF slave_sql_verify_checksum ON slave_transaction_retries 10 slave_transaction_retry_errors 1158,1159,1160,1161,1205,1213,1429,2013,12701 slave_transaction_retry_interval 0 slave_type_conversions slow_launch_time 2 slow_query_log ON slow_query_log_file vaneau22-slow.log socket /run/mysqld/mysqld.sock sort_buffer_size 2097152 sql_auto_is_null OFF sql_big_selects ON sql_buffer_result OFF sql_if_exists OFF sql_log_bin ON sql_log_off OFF sql_mode STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION sql_notes ON sql_quote_show_create ON sql_safe_updates OFF sql_select_limit 18446744073709551615 sql_slave_skip_counter 0 sql_warnings OFF ssl_ca ssl_capath ssl_cert ssl_cipher ssl_crl ssl_crlpath ssl_key standard_compliant_cte ON storage_engine InnoDB stored_program_cache 256 strict_password_validation ON sync_binlog 0 sync_frm ON sync_master_info 10000 sync_relay_log 10000 sync_relay_log_info 10000 system_time_zone CET system_versioning_alter_history ERROR system_versioning_asof DEFAULT table_definition_cache 400 table_open_cache 2000 table_open_cache_instances 5 tcp_keepalive_interval 0 tcp_keepalive_probes 0 tcp_keepalive_time 0 tcp_nodelay ON thread_cache_size 256 thread_handling one-thread-per-connection thread_pool_dedicated_listener OFF thread_pool_exact_stats OFF thread_pool_idle_timeout 60 thread_pool_max_threads 65536 thread_pool_oversubscribe 3 thread_pool_prio_kickup_timer 1000 thread_pool_priority auto thread_pool_size 2 thread_pool_stall_limit 500 thread_stack 299008 time_format %H:%i:%s time_zone SYSTEM tls_version TLSv1.1,TLSv1.2,TLSv1.3 tmp_disk_table_size 18446744073709551615 tmp_memory_table_size 16777216 tmp_table_size 16777216 tmpdir /tmp transaction_alloc_block_size 8192 transaction_prealloc_size 4096 tx_isolation REPEATABLE-READ tx_read_only OFF unique_checks ON updatable_views_with_limit YES use_stat_tables PREFERABLY_FOR_QUERIES userstat OFF version 10.5.21-MariaDB-0+deb11u1-log version_comment Debian 11 version_compile_machine x86_64 version_compile_os debian-linux-gnu version_malloc_library system version_source_revision bed70468ea08c2820647f5e3ac006a9ff88144ac version_ssl_library OpenSSL 1.1.1w 11 Sep 2023 wait_timeout 28800 wsrep_osu_method TOI wsrep_sr_store table wsrep_auto_increment_control ON wsrep_causal_reads OFF wsrep_certification_rules strict wsrep_certify_nonpk ON wsrep_cluster_address wsrep_cluster_name my_wsrep_cluster wsrep_convert_lock_to_trx OFF wsrep_data_home_dir /var/lib/mysql/ wsrep_dbug_option wsrep_debug NONE wsrep_desync OFF wsrep_dirty_reads OFF wsrep_drupal_282555_workaround OFF wsrep_forced_binlog_format NONE wsrep_gtid_domain_id 0 wsrep_gtid_mode OFF wsrep_ignore_apply_errors 7 wsrep_load_data_splitting OFF wsrep_log_conflicts OFF wsrep_max_ws_rows 0 wsrep_max_ws_size 2147483647 wsrep_mysql_replication_bundle 0 wsrep_node_address wsrep_node_incoming_address AUTO wsrep_node_name vaneau22 wsrep_notify_cmd wsrep_on OFF wsrep_patch_version wsrep_26.22 wsrep_provider none wsrep_provider_options wsrep_recover OFF wsrep_reject_queries NONE wsrep_replicate_myisam OFF wsrep_restart_slave OFF wsrep_retry_autocommit 1 wsrep_slave_fk_checks ON wsrep_slave_uk_checks OFF wsrep_slave_threads 1 wsrep_sst_auth wsrep_sst_donor wsrep_sst_donor_rejects_queries OFF wsrep_sst_method rsync wsrep_sst_receive_address AUTO wsrep_start_position 00000000-0000-0000-0000-000000000000:-1 wsrep_strict_ddl OFF wsrep_sync_wait 0 wsrep_trx_fragment_size 0 wsrep_trx_fragment_unit bytes

I have a problem which is similar to https://dba.stackexchange.com/questions/165248/slow-create-table-from-subquery-using-select-inner-join but the solutions provided there have not made any difference for me. I'm using MariaDB 15.1 and have tried this on 2 separate physical machines. One is a production web server (4 GHz, 8 core Xeon with 32 GB RAM and a production grade SSD). The other is my 2021 MacBook Pro (1.4 GHz 4 core Intel, 8 GB RAM, SSD). The performance on the queries doesn't significantly vary in either environment - they are too slow for our application to be considered usable. Our web application allows users to search for chemical substances which are mapped to 1 or more filters. I have eliminated the web application - which is built in PHP - as being the bottleneck. All queries below have been run directly on the database. If I run this query: SELECT s.id FROM substances s WHERE ( exists ( SELECT null FROM filters_substances fs WHERE fs.substance_id = s.id AND fs.filter_id = 2676 ) OR exists ( SELECT null FROM filters_substances fs WHERE fs.substance_id = s.id AND fs.filter_id = 2677 ) OR exists ( SELECT null FROM filters_substances fs WHERE fs.substance_id = s.id AND fs.filter_id = 2678 ) ); This takes approx 0.1 seconds to execute and returns 3 rows. This is fine and I wouldn't expect it to execute quicker than this. We need to write the data returned by that SELECT to another table for the logged-in user of our application. We do this by wrapping the SQL above inside a CREATE TABLE AS statement: CREATE TABLE IF NOT EXISTS tmpdata.filtering_1234 AS SELECT s.id FROM substances s WHERE ( ... ); This creates a table on a separate database (always hosted on the same machine) called tmpdata where the table is named "filtering_1234". The suffix, "_1234", is the logged in user's ID. Although the query above executes successfully it takes approx 3 - 4 seconds. If more filters (fs.filter_id = ) or conditions are added it can take longer, to the point where the web application appears to be un-usable. The CREATE TABLE statement *on it's own* executes in approx 0.1 seconds: CREATE TABLE IF NOT EXISTS tmpdata.filtering_1234(id INT); Query OK, 0 rows affected (0.13 sec) I tried adding the (id INT) part of the statement above to the full query: CREATE TABLE IF NOT EXISTS tmpdata.filtering_1234(id INT) AS SELECT ( ... ) The id column in this case corresponds to the primary key of a table substances where the substances are selected from as per SELECT s.id FROM substances s. I tried adding a separate auto-incrementing primary key - called pk - to the table, as well as the id column for storing the data returned by the select statement: CREATE TABLE IF NOT EXISTS tmpdata.filtering_1234(pk int NOT NULL AUTO_INCREMENT, id INT, PRIMARY KEY(pk)) Again this runs in a similar 3 - 4 seconds. In all cases we get the correct results, i.e. the same 3 substances are always written to filtering_1234. How can I debug this further to find where the bottleneck is? The structure of my tables where the data comes from are: mariadb> DESCRIBE substances; +-------------+-----------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-----------------------+------+-----+---------+----------------+ | id | mediumint(8) unsigned | NO | PRI | NULL | auto_increment | | app_id | varchar(8) | NO | UNI | NULL | | | name | varchar(1500) | NO | | NULL | | | date | date | NO | | NULL | | +-------------+-----------------------+------+-----+---------+----------------+ 4 rows in set (0.01 sec) mariadb> DESCRIBE filters_substances; +--------------+-----------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+-----------------------+------+-----+---------+----------------+ | id | mediumint(8) unsigned | NO | PRI | NULL | auto_increment | | substance_id | mediumint(8) unsigned | NO | MUL | NULL | | | filter_id | smallint(5) unsigned | NO | MUL | NULL | | +--------------+-----------------------+------+-----+---------+----------------+ 3 rows in set (0.00 sec) mariadb> SHOW INDEXES FROM substances; +------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Ignored | +------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+ | substances | 0 | PRIMARY | 1 | id | A | 288989 | NULL | NULL | | BTREE | | | NO | | substances | 0 | app_id | 1 | app_id | A | 288989 | NULL | NULL | | BTREE | | | NO | +------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+ 2 rows in set (0.00 sec) mariadb> SHOW INDEXES from filters_substances; +--------------------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Ignored | +--------------------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+ | filters_substances | 0 | PRIMARY | 1 | id | A | 1626686 | NULL | NULL | | BTREE | | | NO | | filters_substances | 1 | substance_id | 1 | substance_id | A | 813343 | NULL | NULL | | BTREE | | | NO | | filters_substances | 1 | filter_id | 1 | filter_id | A | 70725 | NULL | NULL | | BTREE | | | NO | +--------------------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+ 3 rows in set (0.00 sec)

So I've been trying to configure MariaDB replication for our server. Unfortunately I cannot get it replicating correctly. So I've followed the MariaDB guide to the letter to get replication set up. Master and slave are configured and the slave is set connect to the master. The slave shows the error as: > Lost connection to server at 'waiting for initial communication packet', system error:110 "connection timed out". I've noticed that I am unable to login to the master from the slave with -u root -p -h xxx.xxx.xxx.xxx. Though the servers are able to ping one another and all ports are allowed between the two, I can ssh between them and transfer files. Both replication and root users have the required permissions to login remotely and locally. So I trawled google and implemented some changes to try and further diagnose the issue, such as bind address changes and max packet size. But no luck. I also noticed I am unable to login to the master from the master if I specify its IP address rather than just localhost. I get the error: > ERROR 1045 (28000):access denied for user 'root'@'xxx.xxx.xxx.xxx' (using password: YES). Any ideas will be much appreciated! Master is running the following: Ubuntu server 16:04, MariaDB 10.0.38 Slave is running: Ubuntu server 20.04, MariaDB 10.5.4

I'm investigating the difference in the results given by the same SQL query on two servers running slightly different versions of MariaDB (10.5 and 10.11). Test query is:

SELECT a.Name 
FROM Artist a JOIN Album a2 ON a.ArtistId = a2.ArtistId 
GROUP BY a.ArtistId, a.Name 
HAVING COUNT(a2.AlbumId) IN (
 SELECT * FROM(
  SELECT COUNT(a2.AlbumId)
  FROM Artist a JOIN Album a2 ON a.ArtistId = a2.ArtistId 
  GROUP BY a.ArtistId
  ORDER BY COUNT(a2.AlbumId) DESC
  LIMIT 4) AS t
 )
ORDER BY a.Name;

against the publicly available Chinook database Subquery returns (21,14,11,10). Replacing the subquery by these results:

SELECT ar.Name 
FROM Artist ar
JOIN Album al ON ar.ArtistId = al.ArtistId 
GROUP BY ar.ArtistId, ar.Name 
HAVING COUNT(al.AlbumId) IN (21,14,11,10)
ORDER BY ar.Name;

gives:

Name        |
------------+
Deep Purple |
Iron Maiden |
Led Zeppelin|
Metallica   |
U2          |

which is the expected result. Now, the problem is that when running the first query on MariaDB version 10.11.4 it gives no results (0 rows), but when running it in MariaDB version 10.5.21 it gives the 5 expected rows. Note that the query in itself is not important. What I'm investigating here is the inconsistency in results between two servers that have similar software versions. Also note that the following slightly modified query works (5 rows) on both versions:

SELECT ar.Name, COUNT(al.AlbumId) as num_albums
FROM Artist ar
JOIN Album al ON ar.ArtistId = al.ArtistId 
GROUP BY ar.ArtistId, ar.Name 
HAVING num_albums IN (
  SELECT * FROM (
    SELECT COUNT(al2.AlbumId)
    FROM Album al2 
    GROUP BY al2.ArtistId
    ORDER BY COUNT(al2.AlbumId) DESC
    LIMIT 4
  ) AS t
)
ORDER BY ar.Name;

Is there a recent change in MariaDB that explains the first query results? Or is this a bug in MariaDB that should be reported? EDITED: results are back on server version 11.2. If it was a bug, seems it's solved now. The affected version is the current default on Debian 12 bookworm, so if you encounter a similar problem, updating from the official repository may be a good solution.

This query works without an error (I am running this query in HeidiSQL and 10.5.22-MariaDB) SELECT concat(d.fname, ' ', d.Lname) AS Name, d.EMail, d1.Number FROM orders d LEFT OUTER JOIN phones d1 ON d.EMail = d1.Number where (d.EMail '') HAVING d1.Number IS NULL; If I enclose it in (), I get an error (was getting an error when I used it as a subquery which is why I tried this. ( SELECT concat(d.fname, ' ', d.Lname) AS Name, d.EMail, d1.Number FROM orders d LEFT OUTER JOIN phones d1 ON d.EMail = d1.Number where (d.EMail '') HAVING d1.Number IS NULL; ) The error is > SQL Error (1064): You have an error in your SQL syntax; check the > manual that corresponds to your MariaDB server version for the right > syntax to use near '' at line 6

We recently upgraded from MariaDB 5.5 to MariaDB 10.5 Since doing so, we have a couple of select queries appearing in the slow query log when we backup databases using mysqldump. One of the tables is an InnoDB table with 125,000 records. The other is a MyISAM table with 220,000 records. I guess this might not seem like any great concern, however for many years we never had anything in the slow query log related to mysqldump. So I am wondering if we should be worried? Did the behaviour of mysqldump change between versions 5.5 and 10.5, or could there be some other local setting that we perhaps had optimsied previously, that now isn't? Our slow query time is set to 5 seconds, which is what it was previously. The offending queries are taking just under 6 seconds.

I've a strange problem. A Mariadb replication start failing since this morning. Until today everything works fine from month. This is my scenario: I've a server in a DC which is the master, and a server in another DC (slave) Mysql port on master is open only for the slave network. Since this morning i've the error: >2023-04-27 11:34:06 484086 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.003150' at position 48850240\ 2023-04-27 11:34:08 484086 [ERROR] Slave IO thread did not receive an expected Rows-log end-of-statement for event starting at log 'mysql-bin.003150' position 9686234 whose last block was seen at log 'mysql-bin.003150' position 48833684. The end-of-statement should have been delivered before the current one at log 'mysql-bin.003150' position 48850240\ 2023-04-27 11:34:08 484086 [ERROR] Slave I/O: Relay log write failure: could not queue event from master, Internal MariaDB error code: 1595\ 2023-04-27 11:34:08 484086 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.003150', position 48850240 Stopped the Mysql slave, start slave and everything works fine for another X time (half an hour, one hour it's quite random) When I checked with mysqlbinlog I've this output: >/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;\ /*!40019 SET @@session.max_insert_delayed_threads=0*/;\ /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;\ DELIMITER /*!*/;\ mysqlbinlog: File 'mysqld-relay-bin.001306' not found (Errcode: 2 "No such file or directory") or when I get a real error: >mysqlbinlog: unknown variable 'default-character-set=utf8mb4' Now the second one I've fixed (I hope!) by adding: *[client] loose-default-character-set=utf8mb4* Mariadb version is the same on both master and slave: **Ver 15.1 Distrib 10.5.18-MariaDB** I don't know what else i can try. Does anyone have a hint?