[Maria-discuss] Replication Upgrade Strategy MySQL 5.6 to MariaDB 10.2
Hello,
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?
Thanks,
Mike
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
Thanks for the feedback.
With the slave being set up on a new version from the master, do you see any issue with this?
Best,
Mike
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
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
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
participants (2)
-
Michael Caplan -
Reindl Harald