Our product is an enterprise application with MySQL Enterprise version 5.5.42 deployed in many customer datacenters. We're planning to migrate the MySQL db (bundled with our product) to version 5.7.13. So, when our customers upgrade from X version of product to Y version of our product, we need to upgrade their MySQL 5.5.42 to 5.7.13. Customers would hate to have downtime on this important software.

It appears that we need to migrate first to 5.6 and then to 5.7.

Some questions regarding the upgrade:

  1. Is there a way to have zero downtime without requiring duplicate hardware?
  2. Are there ways to reduce the downtime to a minimum ? If yes, what additional storage requirements will this add?

What else should I know?


1) No. You have to restart MySQL and that means downtime.

2) To minimize the downtime you need an identical server which you can switch to and back. The procedure on high level:

  1. you can build a passive master using percona-xtrabackup for example without downtime

  2. Set up master-master replication

  3. Upgrade the passive master to 5.6 and wait for it to catch up in replication

  4. Switch active master to be the upgraded one (running 5.6)

  5. Stop and rebuild the old master with the same process you did in step #1 but now from the new version (5.6)

  6. Repeat the procedure to upgrade for 5.7

  7. If you don't need it trash the passive master

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.