Galera Cluster for MySQL 8.0.30 released

Codership is pleased to announce a new Generally Available (GA) release of the multi-master Galera Cluster for MySQL 8.0, consisting of MySQL-wsrep 8.0.30 (release notes, download) with Galera replication library 4.13 (release notes, download) implementing wsrep API version 26. This release incorporates all changes to MySQL 8.0.30, adding a synchronous option for your MySQL High Availability solutions.

For the Galera replication library 4.13, we now complete the I/O for the client handshake before starting an asynchronous read to fix an occasional connection failure when establishing new cluster connections. We also now have suppressed the EOF-while-reading errors present when using OpenSSL 3.0 and greater.

In MySQL 8.0.30, we have ensured that it is now compatible with OpenSSL 3.0. We have included the keyring_vault plugin for storing encryption keys inside the HashiCorp Vault.

From a character set and collation standpoint, the audi log character set information asset has been fixed since the default character set changed from utf8 to utf8mb3. Galera now also truncates trailing strings and pads characters according to the collation rules for a given key column.

We have a handful of changes to options. innodb-wsrep-applier-lock-wait-timeout is now made read-write capable. We have deprecated the wsrep_slave_UK_checks variable with the default set to ON. We have made the variable innodb_wsrep_applier_lock_wait_timeout dynamic.

CLONE SST is now cleaned up such that when a joiner is killed it does not reserve the listen port any longer. We have also ensured that all roles are replicated (i.e. CREATE ROLE, DROP ROLE will be replicated cluster-wide).

In very rare instances, we fixed an inconsistency with an import operation where TRUNCATE is issued on a table having a Foreign Key constraint, while there is concurrent DML for the FK parent table. We fixed wsrep-recover crash when gtid_mode=ON.

We do however have one word of warning to all users upgrading from a previous version that happen to use INSTANT ALTER. Users can check whether INSTANT ALTER is used by running:

SELECT NAME FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE TOTAL_ROW_VERSIONS > 0;

If tables with row versions are found, it is recommended to run OPTIMIZE TABLE for those tables before upgrading to 8.0.30. This affects anyone using the XtraBackup SST method: XtraBackup version 8.0.30 refuses to take a backup if INSTANT ALTER use is detected. Therefore optimizing tables with row versions is mandatory for XtraBackup SST to work.

The reason we skipped MySQL 8.0.29 was because we found various bugs related to INSTANT ALTER usage. For reference, there is MySQL Bug #107941 and some were reported in a blog post by Percona: Percona XtraBackup 8.0.29 and INSTANT ADD/DROP Columns. Due to these issues we skipped MySQL 8.0.29, as in the worst case scenario, you would have an unrecoverable database. Data loss is not something we would stand for.

Several INSTANT ALTER bugs were fixed in MySQL 8.0.30 (see ##34233264, #34243694, #34181432, #34302445 in release notes). The bug reported in mysql#10794 is fixed in MySQL 8.0.31 according to the release notes so we backported it.

From the Galera Cluster Enterprise Edition (EE) we also have a 8.0.30 release, and the one difference is: the MySQL variable xa_detach_on_prepare is not supported yet and is ignored by wsrep. The behavior is the same as if the variable value would be off. We have some good news around gcache encryption, and expect a separate blog post about it.

Please download the latest software and update your Galera Clusters! We continue to provide repositories for popular Linux distributions, and we encourage you to use them. Contact us more more information about what Galera Cluster Enterprise Edition can do for you.