Am 29.12.2017 um 16:54 schrieb Michael Caplan:

Thanks for the feedback.

With the slave being set up on a new version from the master, do you see any issue with this?

order is alaways first slaves and then master simply because a newer master version could use statements in the binlog the slave can't cope with whle newer versions are usually backwards compatible MySQL 5.x to MariaDB 10.x is something which needs to be tried anyways because both slightly drift away from another

On 2017-12-29 11:51 AM, Reindl Harald wrote:

...

Am 29.12.2017 um 16:45 schrieb Michael Caplan:

...

Am hoping to get some feedback on an upgrade strategy to go from MySQL 5.6 (two separate servers, one replication slave) to MariaDB 10.2 (installed on new servers).

I'm looking at an rsync process to seed the two new instances on MariaDB, and am unsure if this is sound (https://www.stephenrlang.com/2016/08/setting-up-mysql-master-slave-replicati...). Roughly, the process would look like this:

- rsync data from MySQL 5.6 Master to MariaDB 10.2 Slave - Lock master - Get master status - Refresh rsync - Remove lock - Run upgrade process on MariaDB 10.2 Slave. - Change MASTER.... on MariaDB 10.2 Slave - Create second MariaDB 10.2 Slave from first MariaDB 10.2 Slave - Promote MariaDB 10.2 Slave to Master (redirect all DB traffic at this point) - Redirect other MariaDB 10.2 Slave to new Master - Shutdown MySQL 5.6 servers.

What I'm most concerned about is the viability of rsync as a method to seed the new MariaDB server from MySQL 5.6.  I've come across some chatter that there are risks using rsync instead of a proper dump and restore.  Can anyone comment on this?

i use rsync for a decade now for such things

* hot rsync * shutdown service * second rsync

and do it first usally on the source machine because it minimizes downtime of the master due the second rsync, master is already up, writes his binlog and you can relaxed rsync the copy to the new machine

you just have to delete binlog files in the copy and in case you want to re-start existing replication also on the master itself before start it again