I'm experimenting with MySQL replication with MySQL 5.5.52. My main problem is: how to do "apt-get upgrade" on a master-slave setup properly?
Until now I upgraded the slave then failed over and upgraded the other node as a slave.
So far It worked without problems, but now I found the following: As I upgraded the slave it created some binlogs:
mysql.CREATE TABLE IF NOT EXISTS db (...)
mysql.CREATE TABLE IF NOT EXISTS host (...)
mysql.CREATE TABLE IF NOT EXISTS func (...)
...
As this was the slave node these changes are not replicated to the master, they are lost after the failover.
If I repeat this on the other node after its role is changed from master to slave, the same will happen.
So the changes made by the upgrade will never be committed to the replicated database.
Is this an issue?
How can I avoid this?
Can I upgrade the master-slave setup without (significant) downtime, at all?
Update: So what happens if I do it like I did it in the past?
Node A : master
Node B : slave
On node B (slave): I issue apt-get upgrade, MySQL gets patched. Some binlogs appear on Node B, containing the statements like above. As this is a slave these changes are not replicated to the master.
After Node B is patched I switch the roles (with Corosync-Pacemaker).
After the failover:
Node A : slave
Node B : master
Now the Master MySQL on Node B contains the data that was on Node A prior the failover. As the changes caused by the patching were on a slave, they are NOT in the DB.
If I now patch Node A as a slave the same happens.
So in the end I will have a patched MySQL containing the exact same data it contained prior the patch. All changes the apt-get upgrade process made are "discarded".
^this is wrong^
So it is not discarded, but only applied as soon as the Slave (B) becomes master.
Does this mean I should not wait after patching one node (so patch them both in one run) and always keep the MySQL versions the same?