Codership is pleased to announce a new release of Galera Cluster for MySQL consisting of MySQL-wsrep 5.7.17 GA, 5.6.34, 5.5.54 and Galera 3.20, wsrep API version 25.
This is our GA release in the 5.7 series. Galera Cluster for MySQL 5.7 contains enhancements in multiple key areas, including security, performance and monitoring.
We will continue to provide Galera Cluster 5.5 and 5.6, allowing customers to take advantage of synchronous, multi-master replication without having to upgrade to the latest major MySQL version.
This and future releases will be available from http://www.galeracluster.com.
The source repositories and bug tracking are located at http://www.github.com/codership.
New features and notable fixes in the Galera replication library since last binary release by Codership (3.19):
- Galera can now be compiled with OpenSSL 1.1.0 (GAL-445, codership/galera#407)
- Included asio library would fail to compile with some compilers (GAL-445, codership/galera#407)
- Compilation could fail when compiling on FreeBSD (GAL-476)
- An assertion could happen with two consecutive DDLs run under RSU (GAL-480)
- A scons option, system_asio=0 is now available to prevent using the system asio library when compiling Galera
- Compilation could fail if attempting to compile Galera with GCC 6 (GAL-484)
- An scons option, deterministic_tests=1, is now available to disable non-deterministic Galera unit tests (GAL-470, codership/galera#432)
Notable bug fixes in MySQL-wsrep:
- Using Galera cluster as an asynchronous replication slave with replication filtering could cause holes to form in the GTID sequence (MW-319)
- An assertion could occur if –wsrep_log_conflicts=ON is used and the server was compiled with assertions enabled (MW-28, codership/mysql-wsrep#28)
- If Galera had to perform transaction replaying on a particular transaction, the “affected rows” field in the message returned to the client could be incorrect (MW-329)
- An “OK” message could be sent to the client even if a query was aborted due to a transaction conflict (MW-328)
- An error about a transaction conflict could be delivered to the next client statement, rather than the statement it was about (MW-328)
- Compilation with GCC 6 has been fixed (MW-332)
- Running a ROLLBACK TO SAVEPOINT statement could cause the cluster to hang (MW-253)
New features, notable changes and bug fixes in Oracle MySQL 5.6.34:
- Incompatible Change: The mysqld_safe script has been fortified against various security vulnerabilities
- INSERT operations on a table with an auto_increment key could result in a duplicate key error (Bug #76872)
Known issues with this release:
For Galera Cluster 5.6:
- If using the Ubuntu 16.04 Xenial package, the server can not be bootstrapped using systemd. Please use the SysV init script with the ‘bootstap’ option to bootstrap the node. Note that a server that has been started that way can not be controlled via systemd and must be stopped using the SysV script. Normal server startup and shutdown is possible via systemd.
For Galera Cluster 5.7:
- SST between 5.6 and 5.7 nodes is not supported;
- The –wsrep-replication-bundle option has no effect and may be removed in a future release
- InnoDB tablespaces outside of the data directory are not supported, as they may not be copied over during SST
- Compilation with DTrace enabled may fail, so -DENABLE_DTRACE=0 may be used to disable DTrace
Hi,
thanks a lot for all your work. I have one question to this announcement.
Is MySQL-wsrep 5.7.17 GA really ready for productive use?
We certainly encourage you to try Galera Cluster 5.7 in your test environment to see if it will be beneficial for use in production for your particular case. There have been various changes in MySQL 5.7 outside of Galera replication — apart from various new features, some queries may be optimized differently and the server may behave differently in terms of performance depending on the level of concurrency used (for example, certain high-concurrency scenarios may be optimized better at the expense of low-concurrency ones).