Release Notes for MariaDB Enterprise Server 10.5.15-10

MariaDB Enterprise Server 10.5.15-10 is a Stable (GA) maintenance release of MariaDB Enterprise Server 10.5, released on 2022-03-14

MariaDB Enterprise Server 10.5.15-10 is a maintenance release of MariaDB Enterprise Serverarrow-up-right 10.5. This release includes a variety of fixes.

MariaDB Enterprise Server 10.5.15-10 was released on 2022-03-14.

Fixed Security Vulnerabilities

Notable Changes

  • Galera updated to 26.4.11

  • The maximum values for innodb_ft_cache_size and innodb_ft_total_cache_size have been changed from 80000000 to 1099511627776 (1 TB). (MENT-1428)

  • On Windows, core_file is enabled by default. (MDEV-18439arrow-up-right)

  • New system variables have been added for the HashiCorp Key Management Plugin: (MENT-864)

    • hashicorp_key_management_cache_timeout defines the time (in milliseconds) after which the value of the key stored in the cache becomes invalid, and an attempt to read this data causes a new request to be sent to the vault server. If the value is 0, then the keys will always be considered invalid, but they are still used if the vault server is unavailable and hashicorp_key_management_use_cache_on_timeout is enabled. By default, the value is 60000 (1 minute).

    • hashicorp_key_management_cache_version_timeout defines the time (in milliseconds) after which the information about latest version number of the key (which is stored in the cache) becomes invalid and an attempt to read this information causes a new request to be sent to the vault server. If the value is 0, then information about latest key version numbers always considered invalid, but they are still used if the vault server is unavailable and hashicorp_key_management_use_cache_on_timeout is enabled. By default, the value is 0.

    • For maximum flexibility, both of the new system variables can be configured with the loose prefix:

Issues Fixed

Can result in data loss

  • Columns in some INFORMATION_SCHEMA tables are erroneously declared with DEFAULT clauses, which is not compliant with the SQL standard. (MDEV-18918arrow-up-right)

    • Consequently, when sql_mode=EMPTY_STRING_IS_NULL is set, queries like CREATE TABLE .. SELECT .. FROM INFORMATION_SCHEMA... could encounter replication errors like the following:

Can result in a hang or crash

  • When a FULLTEXT index is added to an InnoDB table with ALGORITHM=INPLACE and the indexed column uses the tis620 character set, the server can crash with a segmentation fault (signal 11). (MDEV-24901arrow-up-right)

  • When MariaDB Server is used on the ARM architecture, which uses a weak memory model, an internal hash table implementation can cause the server to crash with a segmentation fault (signal 11). (MDEV-27088arrow-up-right)

  • When wsrep_sst_method=mariadb-backup and innodb_force_recovery=1 are set with MariaDB Enterprise Cluster, powered by Galera, the joiner node fails to perform an SST. (MDEV-26064arrow-up-right)

    • The SST log contains the following message related to the failure:

  • With MariaDB Enterprise Cluster, when a CREATE TABLE statement that defines a Foreign Key constraint is replicated to other cluster nodes, the nodes could apply the statement in parallel with other DML statements that affect the Foreign Key constraint, which causes the node to fail with an assertion failure. (MDEV-27276arrow-up-right)

  • With MariaDB Enterprise Cluster, when two transactions delete a row from two separate InnoDB tables in parallel and a foreign key causes a delete to cascade for both transactions to the same row in a third table, the server can crash with an assertion failure. (MDEV-26803arrow-up-right, MDEV-26298arrow-up-right)

    • In previous releases, this issue could be avoided by setting wsrep_slave_threads=1.

    • In the MariaDB error log, the following error message about the assertion failure could be written:

  • When an index is dropped and re-adding to a table in a different position using the INPLACE algorithm and the table uses the MEMORY storage engine, the server can crash. (MDEV-25555arrow-up-right)

Can result in unexpected behavior

  • With MariaDB Enterprise Audit, prepared statements can't be used to enable audit logging. (MENT-379)

    • In previous releases, using a prepared statement to set the server_audit_logging system variable would fail with the following error message:

  • When a proxy user is used for authentication, the server checks the proxy user account for the following security controls: (MDEV-26339arrow-up-right)

    • SSL/TLS requirements

    • Account locking

    • Password expiration

    • Starting with this release, the server checks the original user account for the security controls mentioned above.

  • When wsrep_osu_method='TOI' is set with MariaDB Enterprise Cluster, ALTER SEQUENCE is not replicated to other nodes as DDL. (MDEV-19353arrow-up-right)

  • With MariaDB Enterprise Cluster, a race condition in group commit logic could cause cluster nodes to apply transactions in the wrong order, which could cause the server to fail with an assertion. (MDEV-27348arrow-up-right)

    • In the MariaDB Error Log, the message about the assertion failure could look similar to the following: void trx_rseg_update_wsrep_checkpoint(trx_rsegf_t*, const XID*, mtr_t*): Assertion `xid_seqno > wsrep_seqno' failed. [ERROR] mysqld got signal 6 ;

  • When the query cache is enabled and older clients or connectors that don't support the CLIENT_EXTENDED_METADATA capability flag are used, queries could fail with an unknown error. (MDEV-24487arrow-up-right)

  • When JSON is used with single row sub-selects or hybrid functions (such as IF() and COALESCE()), the results could be considered normal strings instead of JSON. (MDEV-27018arrow-up-right)

  • A performance regression exists for updates to InnoDB tables that do not use an index. (MDEV-27499arrow-up-right)

  • With MariaDB Enterprise Cluster, when wsrep_gtid_mode=ON is set and the value of server_id is changed to a new value, transactions still use the old server_id value in GTIDs. (MDEV-26223arrow-up-right)

  • When OFFSET is combined with SELECT DISTINCT, a JOIN, and IN(..), OFFSET is ignored. (MDEV-27382arrow-up-right)

  • When a numeric argument is provided to COLLATE, the server always uses a collation of the latin1 character set instead of a collation of character_set_connection. (MDEV-24584arrow-up-right)

    • When a COLLATE clause specifies a collation of character_set_connection, the query could fail with the following error message:

  • When the mysql.AddGeometryColumn and mysql.DropGeometryColumn stored procedures use the old default DEFINER = 'root@localhost', mariadb-upgradearrow-up-right does not alter them to use the new default DEFINER = 'mariadb.sys@localhost'. (MDEV-27124arrow-up-right)

  • When MariaDB Server is upgraded from 10.2, 10.3, or 10.4, InnoDB upgrades the redo log format in a manner that is not crash-safe. (MDEV-27190arrow-up-right)

Changes in Storage Engines

  • This release incorporates MariaDB ColumnStore storage engine version 5.6.5.

Interface Changes

Platforms

In alignment with the enterprise lifecyclearrow-up-right, MariaDB Enterprise Server 10.5.15-10 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 Policiesarrow-up-right".

Installation Instructions

Upgrade Instructions

This page is: Copyright © 2025 MariaDB. All rights reserved.

spinner

Last updated

Was this helpful?