Changes and Improvements in MariaDB 10.4
MariaDB 10.4 is no longer maintained. Please use a more recent release.
The most recent release of MariaDB 10.4 is:
MariaDB 10.4.34 Stable (GA) Download Now
Contents
MariaDB 10.4 is a previous major stable version. The first stable release of 10.4 was in June 2019, and it was maintained until June 2024.
Implemented Features
See the Differences in MariaDB Enterprise Server 10.4 page for items that are different between MariaDB Community Server 10.4 and MariaDB Enterprise Server 10.4.
Authentication
- See Authentication from MariaDB 10.4 for an overview of the changes.
- The unix_socket authentication plugin is now default on Unix-like systems, which is a major change to authentication in MariaDB (MDEV-12484)
- User password expiry (MDEV-7597)
- Account Locking (MDEV-13095)
- The obsolete mysql.host table is no longer created (MDEV-15851)
- Much faster privilege checks for MariaDB setups with many user accounts or many database grants (MDEV-15649)
- mysql.user table is retired. User accounts and global privileges are now stored in the mysql.global_priv table (MDEV-17658)
- SET PASSWORD support for ed25519 and other authentication plugins (MDEV-12321)
InnoDB
- Added instant DROP COLUMN and changing of the order of columns (MDEV-15562)
- More Instant VARCHAR extension or ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPACT (MDEV-15563)
- change CHAR(0) to any VARCHAR
- change a CHAR that is longer than 255 bytes to VARCHAR or wider CHAR
- change a VARCHAR that is shorter than 128 bytes into any longer VARCHAR
- Instant collation or charset changes for non-indexed columns (MDEV-15564)
- Reduced redo log volume for undo tablespace initialization (MDEV-17138)
- Removed crash-upgrade support for pre-10.2.19 TRUNCATE TABLE (MDEV-13564)
- Added key rotation for innodb_encrypt_log (MDEV-12041)
- Implement innodb_checksum_algorithm=full_crc32 (MDEV-12026)
Optimizer
- Implementation of the optimizer trace, one can enable the optimizer trace by enabling the system variable optimizer_trace (MDEV-6111)
- Engine Independent Table Statistics is now enabled by default; new default values are use_stat_tables=PREFERABLY_FOR_QUERIES and optimizer_use_condition_selectivity=4 (MDEV-15253)
- Two new values for the variable use_stat_tables:
COMPLEMENTARY_FOR_QUERIES
andPREFERABLY_FOR_QUERIES
(MDEV-17255) - Histograms are now collected by default (MDEV-18608).
- analyze_sample_percentage variable added. The default value is 100 (
ANALYZE
will use the whole table), but one can also set analyze to only use a sample of table data to collect the statistics.
- Two new values for the variable use_stat_tables:
- Condition pushdown optimization now has bigger scope:
- Conditions can be pushed into materialized IN-subqueries (MDEV-12387)
- Conditions in
HAVING
clause can be pushed to WHERE. This behavior is controlled through optimizer switch flagcondition_pushdown_from_having
.
- The optimizer switch flag
optimize_join_buffer_size
now defaults toon
(MDEV-17903) - Rowid Filtering optimization added (MDEV-16188). It is controlled through optimizer switch flag
rowid_filter
.
Syntax
- Temporal tables extended with support for application-time periods (MDEV-16973, MDEV-16974, MDEV-16975, MDEV-17082)
- Support of brackets (parentheses) for specifying precedence in UNION/EXCEPT/INTERSECT operations (MDEV-11953)
- New FLUSH SSL command to reload SSL certificates without server restart (MDEV-16266)
- New
CAST
target —CAST(x AS INTERVAL DAY_SECOND(N))
(MDEV-17776) IF NOT EXISTS
clause added to INSTALL PLUGIN andIF EXISTS
clause added to UNINSTALL PLUGIN and UNINSTALL SONAME (MDEV-16294)- Unique indexes can be created on BLOB or TEXT fields (MDEV-371)
Variables
For a list of all new variables, see System Variables Added in MariaDB 10.4 and Status Variables Added in MariaDB 10.4.
- Added to the tcp_nodelay system variable (MDEV-16277)
- Removed the Innodb_pages0_read status variable (MDEV-15705).
- New sql-mode setting,
TIME_ROUND_FRACTIONAL
(MDEV-16991) - New variable gtid_cleanup_batch_size for determining how many old rows must accumulate in the mysql.gtid_slave_pos table before a background job will be run to delete them.
- The default for eq_range_index_dive_limit is now
200
(previously0
) (MDEV-18551) - core_file on Windows now defaults to
ON
(MDEV-18439)
Replication
- Speed up rotation of binary logs,
SHOW BINARY LOGS
etc with optimizing binary log index file locking (MDEV-19116, MDEV-19117). - A new server command, SHUTDOWN WAIT FOR ALL SLAVES, and a new mysqladmin shutdown --wait-for-all-slaves option, are added to instruct the server to wait for the last binlog event to be sent to all connected slaves before shutting down. (MDEV-18450).
Backup
- BACKUP STAGE allows one to implement very efficient backups with minimal locking. MDEV-5336.
Galera 4
In MariaDB 10.4.2 and later, Galera has been upgraded from Galera 3 to Galera 4.
Galera 4 Versions
The following table lists each version of the Galera 4 wsrep provider, and it lists which version of MariaDB each one was first released in. If you would like to install Galera 4 using yum, apt, or zypper, then the package is called galera-4
.
Galera Version | Released in MariaDB Version |
---|---|
26.4.20 | 11.7.1, 11.6.2, 11.4.4, 11.2.6, 10.11.10, 10.6.20, 10.5.27 |
26.4.19 | 11.4.3, 11.2.5, 11.1.6, 10.11.9, 10.6.19, 10.5.26 |
26.4.18 | 11.2.4, 11.1.5, 11.0.6, 10.11.8, 10.6.18, 10.5.25, 10.4.34 |
26.4.16 | 11.2.2, 11.1.3, 11.0.4, 10.11.6, 10.10.7, 10.6.16, 10.5.23, 10.4.32 |
26.4.14 | 10.10.3, 10.9.5, 10.8.7, 10.7.8, 10.6.12, 10.5.19, 10.4.28 |
26.4.13 | 10.10.2, 10.9.4, 10.8.6, 10.7.7, 10.6.11, 10.5.18, 10.4.27 |
26.4.12 | 10.10.1, 10.9.2, 10.8.4, 10.7.5, 10.6.9, 10.5.17, 10.4.26 |
26.4.11 | 10.8.1, 10.7.2, 10.6.6, 10.5.14, 10.4.22 |
26.4.9 | 10.6.4, 10.5.12, 10.4.21 |
26.4.8 | 10.6.1, 10.5.10, 10.4.19 |
26.4.7 | 10.5.9, 10.4.18 |
26.4.6 | 10.5.7, 10.4.16 |
26.4.5 | 10.5.4, 10.4.14 |
26.4.4 | 10.5.1, 10.4.13 |
26.4.3 | 10.5.0, 10.4.9 |
26.4.2 | 10.4.4 |
26.4.1 | 10.4.3 |
26.4.0 | 10.4.2 |
New Features in Galera 4
The mysql
database contains new tables related to Galera replication:
wsrep_cluster
wsrep_cluster_members
wsrep_streaming_log
End users may read but not modify these tables.
The new streaming replication feature allows replicating transactions of unlimited size. With streaming replication, a cluster is replicating a transaction in small fragments during transaction execution. This transaction fragmenting is controlled by two new configuration variables:
wsrep_trx_fragment_unit (bytes, rows, statements)
defines the metrics for how to measure transaction size limit for fragmenting. Possible values are:bytes
: transaction’s binlog events buffer size in bytesrows
: number of rows affected by the transactionstatements
: number of SQL statements executed in the multi-statement transaction
wsrep_trx_fragment_size
defines the limit for fragmenting. When a transaction’s size, in terms of the configured fragment unit, has grown over this limit, a new fragment will be replicated.
Transactions replicated through galera replication will now process the commit phase using MariaDB's group commit logic. This will affect transaction throughput, especially when binary logging is enabled in the cluster.
Limitations in Galera 4
Rolling Upgrades from Galera 3 to Galera 4
Rolling upgrades from MariaDB 10.3 (or earlier) to MariaDB 10.4 also require an upgrade from Galera 3 to Galera 4. Galera 4 has a lot of changes and improvements that were not present in Galera 3.
Prior to the General Availability (GA) releases of MariaDB 10.4 and Galera 4, earlier versions of MariaDB 10.4 and Galera 4 had bugs that could lead to problems if Galera 4 nodes were in a cluster with Galera 3 nodes during a rolling upgrade. In these versions, rolling upgrades were not supported. This meant that, in order to upgrade a cluster, the cluster had to be completely stopped, and the nodes could only be restarted after the entire cluster had been upgraded to MariaDB 10.4 and Galera 4.
These bugs have been fixed in more recent versions, and rolling upgrades from Galera 3 to Galera 4 are supported. In order to perform a rolling upgrade, it is recommended to upgrade to MariaDB 10.4.6 or later and Galera 26.4.2 or later. However, as a general rule, users should try to ensure that they are upgrading to the latest versions of MariaDB 10.4 and Galera 4.
For more detailed information on how to upgrade, see Upgrading from MariaDB 10.3 to MariaDB 10.4 with Galera Cluster.
General
- Crash safe Aria-based system tables (MDEV-16421)
- Added Linux abstract socket support (MDEV-15655)
- Enabled C++11 (MDEV-16410)
- Performance improvements in Unicode collations (MDEV-17534, MDEV-17511, MDEV-17502, MDEV-17474)
- User data type plugins (MDEV-4912, in progress)
- Improvements with SQL standard INTERVAL support to help functions TIMESTAMP()
and ADDTIME() return more predictable results.
- Historically, MariaDB uses the TIME data type for both "time of the day" values and "duration" values. In the first meaning the natural value range is from '00:00:00' to '23:59:59.999999', in the second meaning the range is from '-838:59:59.999999' to '+838:59:59.999999'.
- To remove this ambiguity and for the SQL standard conformance we plan to introduce a dedicated data type INTERVAL that will be able to store values in the range at least from '-87649415:59:59.999999' to '+87649415:59:59.999999', which will be enough to represent the time difference between TIMESTAMP'0001-01-01 00:00:00' and TIMESTAMP'9999-12-31 23:59:59.999999'.
- As a first step we support this range of values for intermediate calculations when TIME-alike string and numeric values are used in INTERVAL (i.e. duration) context, e.g. as the second argument of SQL functions TIMESTAMP(ts,interval) and ADDTIME(ts,interval), so the following can now be calculated:
SELECT ADDTIME(TIMESTAMP'0001-01-01 00:00:00', '87649415:59:59.999999'); -> '9999-12-31 23:59:59.999999' SELECT TIMESTAMP(DATE'0001-01-01', '87649415:59:59.999999') -> '9999-12-31 23:59:59.999999' SELECT ADDTIME(TIME'-838:59:59.999999', '1677:59:59.999998'); -> '838:59:59.999999'
- Support for window UDF functions via the new method x_remove (MDEV-15073)
- Json service for plugins (MDEV-5313)
- Change in behavior for FLUSH TABLES (MDEV-5336).
- The JSON_VALID function is automatically used as a CHECK constraint for the JSON data type alias in order to ensure that a valid json document is inserted (MDEV-13916)
- MariaDB Named Commands (MDEV-17591)
- MariaDB systemd multi-instance service have changed. See systemd page for details.
Security Vulnerabilities Fixed in MariaDB 10.4
For a complete list of security vulnerabilities (CVEs) fixed across all versions of MariaDB, see the Security Vulnerabilities Fixed in MariaDB page.
- CVE-2023-5157: MariaDB 10.4.26
- CVE-2023-22084: MariaDB 10.4.32
- CVE-2022-47015: MariaDB 10.4.29
- CVE-2022-38791: MariaDB 10.4.26
- CVE-2022-32091: MariaDB 10.4.26
- CVE-2022-32089: MariaDB 10.4.26
- CVE-2022-32088: MariaDB 10.4.25
- CVE-2022-32087: MariaDB 10.4.25
- CVE-2022-32086: MariaDB 10.4.25
- CVE-2022-32085: MariaDB 10.4.25
- CVE-2022-32084: MariaDB 10.4.26
- CVE-2022-32083: MariaDB 10.4.25
- CVE-2022-32081: MariaDB 10.4.26
- CVE-2022-31624: MariaDB 10.4.22
- CVE-2022-27458: MariaDB 10.4.25
- CVE-2022-27457: MariaDB 10.4.25
- CVE-2022-27456: MariaDB 10.4.25
- CVE-2022-27455: MariaDB 10.4.25
- CVE-2022-27452: MariaDB 10.4.25
- CVE-2022-27451: MariaDB 10.4.25
- CVE-2022-27449: MariaDB 10.4.25
- CVE-2022-27448: MariaDB 10.4.25
- CVE-2022-27447: MariaDB 10.4.25
- CVE-2022-27446: MariaDB 10.4.25
- CVE-2022-27445: MariaDB 10.4.25
- CVE-2022-27444: MariaDB 10.4.25
- CVE-2022-27387: MariaDB 10.4.25
- CVE-2022-27386: MariaDB 10.4.25
- CVE-2022-27385: MariaDB 10.4.22
- CVE-2022-27384: MariaDB 10.4.25
- CVE-2022-27383: MariaDB 10.4.25
- CVE-2022-27382: MariaDB 10.4.25
- CVE-2022-27381: MariaDB 10.4.25
- CVE-2022-27380: MariaDB 10.4.25
- CVE-2022-27379: MariaDB 10.4.25
- CVE-2022-27378: MariaDB 10.4.25
- CVE-2022-27377: MariaDB 10.4.25
- CVE-2022-27376: MariaDB 10.4.25
- CVE-2022-24052: MariaDB 10.4.23
- CVE-2022-24051: MariaDB 10.4.23
- CVE-2022-24050: MariaDB 10.4.23
- CVE-2022-24048: MariaDB 10.4.23
- CVE-2022-21595: MariaDB 10.4.23
- CVE-2022-21451: MariaDB 10.4.19
- CVE-2022-21427: MariaDB 10.4.25
- CVE-2022-0778: MariaDB 10.4.23
- CVE-2021-46669: MariaDB 10.4.25
- CVE-2021-46668: MariaDB 10.4.24
- CVE-2021-46667: MariaDB 10.4.22
- CVE-2021-46666: MariaDB 10.4.20
- CVE-2021-46665: MariaDB 10.4.24
- CVE-2021-46664: MariaDB 10.4.24
- CVE-2021-46663: MariaDB 10.4.24
- CVE-2021-46662: MariaDB 10.4.22
- CVE-2021-46661: MariaDB 10.4.24
- CVE-2021-46659: MariaDB 10.4.23
- CVE-2021-46658: MariaDB 10.4.21
- CVE-2021-46657: MariaDB 10.4.20
- CVE-2021-35604: MariaDB 10.4.22
- CVE-2021-27928: MariaDB 10.4.18
- CVE-2021-2389: MariaDB 10.4.21
- CVE-2021-2372: MariaDB 10.4.21
- CVE-2021-2194: MariaDB 10.4.16
- CVE-2021-2166: MariaDB 10.4.19
- CVE-2021-2154: MariaDB 10.4.19
- CVE-2021-2144: MariaDB 10.4.9
- CVE-2021-2022: MariaDB 10.4.14
- CVE-2021-2007: MariaDB 10.4.7
- CVE-2020-7221: MariaDB 10.4.12
- CVE-2020-2922: MariaDB 10.4.7
- CVE-2020-28912: MariaDB 10.4.16
- CVE-2020-2814: MariaDB 10.4.13
- CVE-2020-2812: MariaDB 10.4.13
- CVE-2020-2780: MariaDB 10.4.9
- CVE-2020-2760: MariaDB 10.4.13
- CVE-2020-2752: MariaDB 10.4.13
- CVE-2020-2574: MariaDB 10.4.12
- CVE-2020-15180: MariaDB 10.4.15
- CVE-2020-14812: MariaDB 10.4.16
- CVE-2020-14789: MariaDB 10.4.16
- CVE-2020-14776: MariaDB 10.4.16
- CVE-2020-14765: MariaDB 10.4.16
- CVE-2020-13249: MariaDB 10.4.13
- CVE-2019-2974: MariaDB 10.4.9
- CVE-2019-2938: MariaDB 10.4.9
- CVE-2019-2805: MariaDB 10.4.7
- CVE-2019-2758: MariaDB 10.4.7
- CVE-2019-2740: MariaDB 10.4.7
- CVE-2019-2739: MariaDB 10.4.7
- CVE-2019-2737: MariaDB 10.4.7
- CVE-2019-2628: MariaDB 10.4.5
- CVE-2019-2627: MariaDB 10.4.5
- CVE-2019-2614: MariaDB 10.4.5
- CVE-2018-25032: MariaDB 10.4.26