The much anticipated release of Galera 4 makes its way first in the latest release of MariaDB Server 10.4.3 Release Candidate which you can download now. Congratulations to MariaDB Corporation and MariaDB Foundation on this release candidate — please get testing Galera 4, and share your feedback with us via our Google Group discussion list! Do not forget that you can always reach us via email: mailto:info@galeracluster.com and via our contact us form.

The feature we are excited about the most, is a feature request from many users. This is none other than huge transaction support, since large write transactions are processed on the “master” node until commit time, and there have long been configuration options to prevent large transactions. Galera 4 implements streaming replication, which means it is now possible to replicate transactions of any size, while still keeping existing transaction size limits. In MariaDB, it also makes use of the group commit in the binary log (group commit is enabled for both regular replication and streaming transactions), so if you have binary logging enabled, this may be of interest to you from a throughput standpoint. How does all this work? The transaction itself is replicated in small increments, and there is a configurable size threshold. Replicated rows itself are locked and cannot be conflicted. A point of note: LOAD DATA has been refactored to work with streaming replication, so there are no intermediate commits during such processing.

As a MariaDB user, to perform State Transfer Snapshots (SSTs), you will be using Mariabackup. The server itself has backup locks, fixed in MariaDB Server 10.4.2. All in, this should be helpful for mariabackup SST.

If you look at the mysql database, there are several new tables of interest: wsrep_cluster, wsrep_cluster_members, and wsrep_streaming_log. As a DBA, you can utilise wsrep_cluster and wsrep_cluster_members to visualise the currently active nodes in your cluster.

To implement causal reads from the application, there are also 3 new functions that will benefit developers in Galera 4: WSREP_LAST_WRITTEN_GTID(), which returns the Global Transaction ID (GTID) that corresponds to the last write transaction made by the client, WSREP_LAST_SEEN_GTID(), which returns the GTID of the last write transaction that was observed by the client, and WSREP_SYNC_WAIT_UPTO_GTID(), which requires a GTID in the argument, and blocks the client until the GTID provided has been applied and committed on the node, or until a timeout occurs.

Some understated features that have been present since Galera 3.x include intelligent donor selection and cluster crash recovery. These were originally planned for Galera 4, but made it into earlier releases largely due to customer requirements.

When it comes to donor node selection in Galera 3, the State Snapshot Transfer (SST) donor was selected at random. However with Galera 4, you get a much more intelligent choice when it comes to choosing a donor, as it will favour a donor that can provide an Incremental State Transfer (IST), or pick a donor in the same segment. As a database administrator (DBA), you can force this via setting wsrep_sst_donor.

No matter where you host your Galera Cluster, there is a chance that the data center suffers a catastrophic power outage taking out your entire set of nodes in that data center (you of course were running with data center High Availability in mind, and have another, right?) for a timeframe. When power gets restored, you typically had to bootstrap a node to be a new cluster and then start MariaDB on the other nodes (since nodes can automatically join a cluster, but first a node must be elected!). You now have a new option, pc.recovery=ON which means that all nodes maintain cluster group information persistently, and upon a shutdown/restart scenario, the full group continues to start in the same configuration! This is a huge win from an automation standpoint as it means the DBA does not have to be on call during the restart.

By now, you are probably wanting to update a test cluster from an earlier MariaDB version. Currently, rolling upgrades of an idle 10.3 Galera Cluster can be migrated to a 10.4 Galera Cluster with Galera 4. It should also be safe to direct DML only workloads to a mixed cluster during said process, however the 10.4 nodes should be read only and writes should be directed to the 10.3 nodes.

However, the safest way might be to do a node-by-node upgrade from MariaDB 10.3 to the current MariaDB 10.4 release candidate. So the best way to do this, as quoted in the MariaDB release notes is to:

• Install MariaDB 10.4.2 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
• Restart MariaDB Server with the proper wsrep_provider, and it will join the cluster topology

Note that the update operation should be done fast enough so that joining will happen with Incremental State Transfer (IST). If the 10.4 node joins back with SST, the data directory would be overwritten with the old 10.3 data directory from the donor node.

So, what are you waiting for? Try out MariaDB 10.4.3 Release Candidate with Galera 4 today! As always, don’t forget to drop feedback at our Google Group discussion list. We will also be monitoring the maria-discuss and maria-developers lists, as well as MariaDB’s Jira for any pesky bugs or feature enhancement feedback!