Release Notes for MariaDB Enterprise Server 10.5.26-20

Overview

MariaDB Enterprise Server 10.5.26-20 is a maintenance release of MariaDB Enterprise Server 10.5. This release includes a variety of fixes.

MariaDB Enterprise Server 10.5.26-20 was released on 2024-09-09.

Backports

  • The JSON functions JSON_ARRAY_INTERSECT, JSON_OBJECT_TO ARRAY, and JSON_FILTER_KEYS have been backported from later MariaDB Community Server Release Series to enhance the JSON function coverage in this MariaDB Enterprise Server release series. (MENT-1897)

    • The new JSON function JSON_ARRAY_INTERSECT(<array1>, <array2>) is used to find the intersection between two JSON arrays.

      Example:

      SET @array1= '[1,2,3]';
SET @array2= '[1,2,4]';
SELECT json_array_intersect(@array1, @array2) as result;
+--------+
| result |
+--------+
| [1, 2] |
+--------+
SET @json1= '[[1,2,3],[4,5,6],[1,1,1]]';
SET @json2= '[[1,2,3],[4,5,6],[1,3,2]]';
SELECT json_array_intersect(@json1, @json2) as result;
+------------------------+
| result                 |
+------------------------+
| [[1, 2, 3], [4, 5, 6]] |
+------------------------+

    • The new JSON function JSON_OBJECT_TO_ARRAY(<json_doc>) is used to convert all JSON objects found in a JSON document to JSON arrays where each item in the outer array represents a single key-value pair from the object.

      Example:

      SET @json1= '{ "a" : [1,2,3] , "b": {"key1": "val1", "key2": {"key3": "val3"}} }';
SELECT JSON_OBJECT_TO_ARRAY(@json1) as result;
+-----------------------------------------------------------------------+
| result                                                                |
+-----------------------------------------------------------------------+
| [["a", [1, 2, 3]], ["b", {"key1": "val1", "key2": {"key3": "val3"}}]] |
+-----------------------------------------------------------------------+

      Resulting arrays can be compared using JSON_ARRAY_INTERSECT():

      SET @json1='{"a":[1,2,3],"b":{"key1":"val1","key2":{"key3":"val3"}}}';
SET @json2='{"a":[1,2,3]}';
SELECT JSON_OBJECT_TO_ARRAY(@json1) into @array1;
SELECT JSON_OBJECT_TO_ARRAY(@json2) into @array2;
SELECT JSON_ARRAY_INTERSECT(@array1,@array2) as result;
+--------------------+
| result             |
+--------------------+
| [["a", [1, 2, 3]]] |
+--------------------+

    • The new JSON function JSON_OBJECT_FILTER_KEYS(<json_doc>,<array_keys>) returns key/value pairs from a JSON string for keys defined in <array_keys>.

      Example:

      SET @json1= '{ "a": 1, "b": 2, "c": 3}';
SELECT JSON_OBJECT_FILTER_KEYS (@json1, ' ["b", "c"] ') as result;
+------------------+
| result           |
+------------------+
| {"b": 2, "c": 3} |
+------------------+

      By using JSON_ARRAY_INTERSECT() and JSON_KEY() as arguments for JSON_OBJECT_FILTER_KEYS(), a comparison of two JSON strings is possible where only the same keys are compared, not the key/value pairs.

      Example (only show key/value pairs of json1 where the key exists in json2):

      SET @json1= '{ "a": 1, "b": 2, "c": 3}';
SET @json2= '{"b" : 10, "c": 20, "d": 30}';
SELECT JSON_OBJECT_FILTER_KEYS (@json1, json_array_intersect(json_keys(@json1), json_keys(@json2))) as result;
+------------------+
| result           |
+------------------+
| {"b": 2, "c": 3} |
+------------------+

  • The new JSON function JSON_KEY_VALUE(<json_doc>,<json_path>) extracts key/value pairs from a JSON object. The JSON path parameter is used to only return key/value pairs for matching JSON objects. (MENT-1896)

    Example:

    SELECT JSON_KEY_VALUE('[[1, {"key1":"val1", "key2":"val2"}, 3], 2, 3]', '$[0][1]');
+-----------------------------------------------------------------------------+
| JSON_KEY_VALUE('[[1, {"key1":"val1", "key2":"val2"}, 3], 2, 3]', '$[0][1]') |
+-----------------------------------------------------------------------------+
| [{"key": "key1", "value": "val1"}, {"key": "key2", "value": "val2"}]        |
+-----------------------------------------------------------------------------+

    The function JSON_KEY_VALUE() can be used as an argument to JSON_TABLE(), which allows adding the key to a result set.

    Example:

    SELECT jt.* FROM JSON_TABLE(
JSON_KEY_VALUE('[[1, {"key1":"val1", "key2":"val2"}, 3], 2, 3]', '$[0][1]'),'$[*]'
COLUMNS (
k VARCHAR(20) PATH '$.key',
v VARCHAR(20) PATH '$.value',
id FOR ORDINALITY )) AS jt;
+------+------+------+
| k    | v    | id   |
+------+------+------+
| key1 | val1 |    1 |
| key2 | val2 |    2 |
+------+------+------+

Notable Changes

  • A new global variable server_uid can be used to identify a server instance. This Server ID is also logged in the error log file on startup (MDEV-34311)

  • Galera has been updated to 26.4.19

Changes in Storage Engines

  • This release incorporates MariaDB ColumnStore engine version 5.6.8.

Issues Fixed

Can result in data loss

  • An ALTER TABLE, OPTIMIZE TABLE, or REPAIR TABLE on an Aria table of ROW_FORMAT=PAGE (default) can fail or possibly corrupt the table, if the data file is bigger than 4GB. (MDEV-34522)

  • When executing an ALTER TABLE <table> CHECK PARTITION <partition> FOR UPGRADE on a table, which was created by the same server version, and therefore does not need an upgrade, a following ALTER TABLE for the same table will result in a server crash. (MDEV-32155)

Can result in hang or crash

  • When using SHOW CREATE DATABASE statement crashes the server with a database name containing Unicode characters, the server can crash (MDEV-32376)

  • For a partitioned table of type SPIDER where the remote connection is configured via CREATE SERVER, the server can crash if the server definition was removed via DROP SERVER (MDEV-31475)

  • When multiple threads try to load spider and to create a spider table, MariaDB can crash (MDEV-32487)

  • When enabling the PAGE_COMPRESSED option for an InnoDB table created with INNODB_DEFAULT_ROW_FORMAT=redundant, the server crashes. (MDEV-34222)

  • A query that plans to use the Rowid Filter optimization could crash the server if some factor causes it to terminate abnormally at a certain specific point in query optimization. Examples of such causes of termination are: (MDEV-30651)

    • Query being killed with KILL statement

    • Statement execution exceeding @@max_statement_time limit

  • When running a query with HAVING NOT column clause where the "column" is also used in the GROUP BY {{ ... SELECT ... GROUP BY column ... HAVING NOT column}}, the server can crash. Other forms of HAVING clause were not affected (MDEV-19520)

  • An Auto-generated DELETE statement is added to the binary log for MEMORY tables, which can break replication. The DELETE cannot be executed in cases like missing triggers, which results in the replication being stopped. (MDEV-25607)

  • Replication fails when XA transactions are used where the replica has replicate_do_db set and the client has touched a different database when running DML such as inserts (MDEV-33921)

  • Replication fails in chain configurations if an XA transaction is replicated which results in an empty transaction on a replica. The XA START through XA PREPARE first phase of the transaction is not binlogged, yet the XA COMMIT is binlogged, which results in errors due to executing standalone XA COMMIT queries on replicas further in the chain. (MDEV-33921)

  • The server can crash for a query with a HAVING clause such that: (MDEV-32293) (MDEV-32424) (MDEV-32304) (MDEV-29363)

  1. It has several references to the same non-trivial constant (e.g., a subquery),

  2. Condition pushdown optimization would try to move at least one of the references from HAVING clause into WHERE

  • If a query used a derived table (a CTE or a mergeable VIEW would work as well) and the WHERE clause compared columns of the derived table with the value of CHARSET() or COERCIBILITY() function, the query could produce wrong result, or crash. The cause was incorrect processing of these functions by derived condition pushdown optimization (MDEV-33010)

Can result in unexpected behavior

  • Replicas only read the first 41 characters of MASTER_PASSWORD from the master.info file. This leads to an access denied error for a replica on a server restart, if the password is > 41 characters long. (MDEV-23857)

  • Mariabackup stores the password into the tool_command setting in the file xtrabackup_info, if the password is provided as command-line option (MDEV-34434)

  • The semi-sync binlog fail-over recovery process uses rpl_semi_sync_slave_enabled==TRUE as its condition to truncate a primary server's binlog, as it is anticipating the server to re-join a replication topology as a replica. However, for servers configured with both rpl_semi_sync_master_enabled=1, and rpl_semi_sync_slave_enabled=1, if a primary is just re-started (i.e., retaining its role as master), it can truncate its binlog to drop transactions which its replica(s) has already received, and executed. (MENT-2122)

    • If this happens, when the replica reconnects, its gtid_slave_pos can be ahead of the recovered primary's gtid_binlog_pos, resulting in an error state where the replica's state is ahead of the primary's.

    • Option --init-rpl-role will be used to define the initial role a server has. Possible options are MASTER and SLAVE, default MASTER . Setting it to SLAVE is now the condition for semi-sync recovery to truncate the binlog, This allows for both rpl_semi_sync_master_enabled, and rpl_semi_sync_slave_enabled to be set for a primary that is restarted, and no transactions will be lost, so long as --init-rpl-role is not set to SLAVE

  • Command-line option 'defaults-group-suffix=' cannot be used with the script mariadb-secure-installation (MDEV-33265)

  • Grouping operators referring to column aliases in unions inside derived tables can cause name resolution problems with prepared statements. (MDEV-34506)

  • Table mysql.gtid_slave_pos is replicated between two MariaDB Enterprise Cluster although wsrep_gtid_mode=OFF is set. (MDEV-34170)

  • wsrep_sst_mariabackup is using /tmp dir during SST instead of an user defined tmpdir (MDEV-32158)

  • The following misleading error message is shown with MariaDB Enterprise Cluster. Galera can mark user threads as high priority and so they can't be killed: (MDEV-12008)

    You are not the owner of the thread ....

    • Now the following error message is shown:

      This is a high priority thread/query and cannot be killed without compromising the consistency of the cluster

  • Executing an INSERT statement in PS mode having positional parameters bound with an array can result in an incorrect number of inserted rows in case there is a BEFORE INSERT trigger that executes yet another INSERT statement to put a copy of the row being inserted into some table. (MDEV-24411)

  • When using the asynchronous replication between two MariaDB Enterprise Cluster (Galera) environments, the domain id of the GTID can be wrongly set, or changed by Galera (MDEV-32633)

Changelog

For the complete list of changes in this release, see the changelog.

Platforms

In alignment to the enterprise lifecycle, MariaDB Enterprise Server 10.5.26-20 is provided for:

  • AlmaLinux 8 (x86_64, ARM64)

  • AlmaLinux 9 (x86_64, ARM64)

  • Debian 11 (x86_64, ARM64)

  • Debian 12 (x86_64, ARM64)

  • Microsoft Windows (x86_64) (MariaDB Enterprise Cluster excluded)

  • Red Hat Enterprise Linux 8 (x86_64, ARM64)

  • Red Hat Enterprise Linux 9 (x86_64, ARM64)

  • Rocky Linux 8 (x86_64, ARM64)

  • Rocky Linux 9 (x86_64, ARM64)

  • SUSE Linux Enterprise Server 12 (x86_64)

  • SUSE Linux Enterprise Server 15 (x86_64, ARM64)

  • Ubuntu 20.04 (x86_64, ARM64)

Some components of MariaDB Enterprise Server might not support all platforms. For additional information, see "MariaDB Corporation Engineering Policies".