maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

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-replication-with-rsync/). 
> > > 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