Nicht, dass ich im Allgemeinen zu extremer Prokrastination neige, aber im Falle des netten kleinen ToDos „Update der MySQL-Server auf 5.5“ bin ich eindeutig schuldig. Das schob ich nämlich bereits seit Ende 2012 leise vor mir her, da ich den Aufwand für außerordentlich hoch hielt. Zur Ausgangssituation: Aus historischen Gründen hatten wir eine recht heterogene Landschaft im Bereich MySQL-DB-Server, bestehend aus:
* 1 Master-Slave-Cluster, Version 5.1, basierend auf original MySQL-RPMs
* 2 Master-Slave-Clustern, Version 5.1, basierend auf IUS-RPMs
* 1 Master-Slave-Cluster, Version 5.5, basierend auf original MySQL-RPMs
* 1 Master-Master-Cluster, Version 5.1, basierend auf original MySQL-RPMs
Wohlgemerkt: Alle auf RHEL5! Die nun alle auf eine homogene Basis zu stellen (nämlich Version 5.5, basierend auf IUS-RPMs) und dabei sowohl die Daten als auch die Replikation leben zu lassen, schien nur durch komplette Dump-Restores mit zwischenzeitlicher Neuinstallation der Pakete zu funktionieren. Da wir hier über eine Datenmenge von insgesamt etwa einem Terabyte sprechen, rechnete ich mit einer ziemlich großen Downtime.
Ein wenig Recherche nach der optimalen Vorgehensweise brachte jedoch zutage, dass die Jungs und Mädels der IUS Community (http://iuscommunity.org), deren Repositories wir ja auch oft und gerne benutzen, tatsächlich auch an solche wirren Zustände gedacht haben. Genauer gesagt gibt es das hübsche Plugin „replace“ für die Paketverwaltung yum. Es lässt sich – natürlich nach Integration des IUS-Repos – per „yum install yum-plugin-replace“ installieren und eröffnet die Möglichkeit, yum mit der Option „replace-with“ aufzurufen.
So führt das folgende Kommando bspw. dazu, dass ein bisheriger 5.1-Server auf IUS-Basis nahtlos durch einen 5.5-Server ersetzt wird:
yum replace mysql51-libs --replace-with mysql55-libs
Der Wechsel ist aber – und das ist das eigentliche Erstaunliche – auch aus den MySQL-RPMs heraus möglich:
yum replace MySQL-server-community --replace-with mysql55-server
yum bzw. das Plugin löst selbst alle nötigen Abhängigkeiten auf. Ggf. beschwert es sich, dass die Herkunft einiger beteiligter Pakete nicht ermittelt werden konnte, dies kann man aber problemlos ignorieren.
Letztendlich war es mir so möglich, das gefürchtete Upgrade für alle Server in einer Stunde durchzuführen, ohne dass ich bislang ein Problem feststellen konnte. Einige Hinweise gilt es aber noch zu beachten:
- Laut MySQL sollte immer der Slave zuerst aktualisiert werden.
- Nach dem Upgrade von Slave und Master muss auf dem Master das Kommando „mysql_upgrade“ ausgeführt werden, um fehlende MySQL-Tabellen zu ergänzen. Zudem werden bei der Gelegenheit alle Tabellen geprüft und ggf. repariert.
- Beim Wechsel von MySQL 5.5 aus MySQL-RPMs auf MySQL 5.5 aus IUS-RPMs musste ich zuvor manuell das Paket „MySQL-shared-compat“ entfernen. Das konnte das Plugin aus irgendwelchen Gründen nicht lösen.
- Bei Statement-basierter Replikation wirft MySQL 5.5 im Gegensatz zu 5.1 Warnungen, wenn Anweisungen bspw. nicht-deterministische Ergebnisse liefern. Diese Warnungen waren nicht zu unterdrücken (jedenfalls habe ich den Schalter nicht gefunden), obwohl wir uns der Tatsache bewusst waren und die entsprechende Datenbank ohnehin von der Replikation ausgenommen hatten. Ein somit ohnehin fälliger Wechsel zum „Mixed“-Format war also unvermeidlich (Schalter „binlog-format = MIXED“)
- In MySQL 5.5 fallen einige Konfigurationsoptionen weg bzw. sollten durch ihre Nachfolger ersetzt werden. Die Ersetzung kann bereits vor dem Upgrade in der my.cnf durchgeführt werden. Aufgefallen sind bei mir:
- skip-locking
- log-err (ersetzt durch log-error)
- key_buffer (ersetzt durch key_buffer_size)
- thread_cache (ersetzt durch thread_cache_size)