[ClusterLabs] Mysql upgrade in DRBD setup

Ken Gaillot kgaillot at redhat.com
Thu Oct 12 15:21:47 EDT 2017


On Thu, 2017-10-12 at 18:51 +0200, Attila Megyeri wrote:
> Hi all,
>  
> What is the recommended mysql server upgrade methodology in case of
> an active/passive DRBD storage?
> (Ubuntu is the platform)

If you want to minimize downtime in a MySQL upgrade, your best bet is
to use MySQL native replication rather than replicate the storage.

1. starting point: node1 = master, node2 = slave
2. stop mysql on node2, upgrade, start mysql again, ensure OK
3. switch master to node2 and slave to node1, ensure OK
4. stop mysql on node1, upgrade, start mysql again, ensure OK

You might have a small window where the database is read-only while you
switch masters (you can keep it to a few seconds if you arrange things
well), but other than that, you won't have any downtime, even if some
part of the upgrade gives you trouble.

>  
> 1)      On the passive node the mysql data directory is not mounted,
> so the backup fails (some postinstall jobs will attempt to perform
> manipulations on certain files in the data directory).
> 2)      If the upgrade is done on the active node, it will restart
> the service (with the service restart, not in a crm managed
> fassion…), which is not a very good option (downtime in a HA
> solution). Not to mention, that it will update some files in the
> mysql data directory, which can cause strange issues if the A/P pair
> is changed – since on the other node the program code will still be
> the old one, while the data dir is already upgraded.
>  
> Any hints are welcome!
>  
> Thanks,
> Attila
>  
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.
> pdf
> Bugs: http://bugs.clusterlabs.org
-- 
Ken Gaillot <kgaillot at redhat.com>




More information about the Users mailing list