The most recent release of MariaDB 10.4 is:MariaDB 10.4.34 Stable (GA) Download Now
Download | Release Notes | Changelog | Overview of 10.4
Release date: 29 Jan 2019
MariaDB 10.4 is the current development series of MariaDB. It is an evolution of MariaDB 10.3 with several entirely new features not found anywhere else and with backported and reimplemented features from MySQL.
MariaDB 10.4.2 is a Beta release.
Do not use beta releases in production!
For an overview of MariaDB 10.4 see theWhat is MariaDB 10.4? page.
Thanks, and enjoy MariaDB!
Notable changes of this release include:
4 version 26.4.0 has been added in this release, see the Galera 4 Notes section for details
()
a number of bugs related to Instant DROP COLUMN have been fixed
New variable, for limiting the number of failed connection attempts by a user.
Rolling upgrades from earlier 10.3 (or older) MariaDB releases are not supported in this release. For upgrading a 10.3-based cluster, any applications accessing the cluster should be stopped and the cluster shut down. Then for each cluster node the following procedure should be carried out:
Install and Galera 4 version 26.4.0
Start MariaDB server, but make sure it is not trying to connect to the cluster by configuring wsrep_provider=none
While MariaDB server is running, run mysql_upgrade for the server
After that, you can bootstrap the cluster. If there was ongoing application load on the cluster during the initial cluster shutdown phase, you should make sure to bootstrap the cluster with the node which was shutdown last.
We are working on rolling upgrade support for the final GA version of . With a rolling upgrade, a live cluster can be upgraded node by node, and the cluster is able to process application load when having a hybrid setup of 10.3 and 10.4 nodes.
The ‘mysql’ schema contains new Galera replication related tables:
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:
(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 bytes
rows: number of rows affected by the transaction
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.
Upgrading from 10.3 version 25.3.25 to 10.4.2 version 26.4.0 must happen on a stopped cluster. Only after all nodes have been upgraded to and Galera 26.4.0 can the cluster be started up
Splitting transactions of LOAD DATA execution will conflict with
streaming replication, and should not be used if streaming replication is
configured
Fixes for the following :
For a complete list of changes made in , with links to detailed information on each push, see the .
For a full list of contributors to , see the .
Do not use beta releases in production!
MDEV-17475: Maximum value of is now 2097152.
statements: number of SQL statements executed in the multi-statement
transaction
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.
CVE-`-```
This page is licensed: CC BY-SA / Gnu FDL