Announcing Galera Cluster 5.7 Beta

[Philip Stoev]

Codership is pleased to announce a beta release of Galera Cluster for MySQL
5.7, consisting of MySQL-wsrep 5.7.15 and Galera 3.18.

Galera Cluster for MySQL 5.7 contains enhancements in multiple key areas,
including security, performance and monitoring.

This is a beta-quality release and should not be used in production, however
we encourage you to give it a try and we welcome all feedback. You can use
the bug tracker at https://github.com/codership/mysql-wsrep/issues to submit
issues or you can email us at in...@galeracluster.com.

This release incorporates all changes up to MySQL 5.7.15 and is available as
targeted packages and package repositories for Ubuntu 16.06 and CentOS 7
that can be downloaded from http://www.galeracluster.com.

Notable changes in this release:

* If needed, initialization of the initial MySQL database can be performed
using the --initialize command:

sudo
/usr/sbin/mysqld --user=mysql --initialize --log-error=/tmp/mysqld_initialize.log

* On systemd systems, bootstrapping the first node of the cluster is
performed using the following command:

sudo /usr/bin/mysqld_bootstrap

Known issues with this release:

* Mixed-version clusters containing both 5.6 and 5.7 nodes are not supported
* GTID mode and associated options are not supported and may cause the
applier thread to abort;
* Running the mysqld_upgrade script should be done while the wsrep_provider
is not loaded;
* 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 get copied over during SST;
* Compilation with DTrace enabled may fail, so -DENABLE_DTRACE=0 may be used
to disable DTrace.
* Packages for RHEL, Debian, and Ubuntu 14.04 will be provided with the GA
release.

[Philip Stoev]

[mnic...@pivotal.io]

Hi, we noticed one item, and would like to follow up:

> Mixed-version clusters containing both 5.6 and 5.7 nodes are not supported

Is this an effect of being Beta, or is it the intention when 5.7 becomes Generally Available, that it will be necessary to take a Galera cluster entirely offline in order to upgrade?

Thank you, looking forward to the new release.

[Philip Stoev]

Hello,

From our testing, it seems that at-will SST using xtrabackup or rsync
between 5.6 and 5.7 nodes will not be possible, so long-term coexistence
between 5.6 and 5.7 nodes within the same cluster will be problematic.

However, IST should work and therefore rolling upgrades can be made. We will
publish a procedure for that as soon as we have exhaustively tested it.

Thank you.

Philip Stoev

--
You received this message because you are subscribed to the Google Groups
"codership" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to codership-tea...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jörg Brühe]

Hi!

On 20.10.2016 09:34, Philip Stoev wrote:
> Hello,
>
> From our testing, it seems that at-will SST using xtrabackup or rsync
> between 5.6 and 5.7 nodes will not be possible, so long-term coexistence
> between 5.6 and 5.7 nodes within the same cluster will be problematic.

Given the changes just in the "user" table from 5.6 to 5.7, I'm not
surprised at all.
After an SST via xtrabackup or rsync (= a physical copy) from 5.6 to 5.7
you would need to run "mysql_upgrade", and Galera is not designed to do
that.
Even worse, such an SST from 5.7 to 5.6 would be a downgrade, and MySQL
is not designed to allow that.
There may be additional problem areas which didn't yet come to my mind.

>
> However, IST should work and therefore rolling upgrades can be made. We
> will publish a procedure for that as soon as we have exhaustively tested
> it.

AIUI, both IST and normal Galera operation have similarities with
traditional replication, and that is also not supported (by MySQL) from
a newer master to an older slave (even though it may often work).
For me, this implies you should keep the release series mix between 5.6
and 5.7 to as short a period as possible, make sure that all changes
flow "upward", and do the rolling upgrade (once we have a tested
procedure for it) of the nodes in close succession.


Regards,
Jörg

--
Joerg Bruehe, Senior MySQL Support Engineer, joerg....@fromdual.com
FromDual GmbH, Rebenweg 6, CH - 8610 Uster; phone +41 44 500 58 26
Geschäftsführer: Oliver Sennhauser
Handelsregister-Eintrag: CH-020.4.044.539-3