Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

MariaDB von 10.4 auf 10.5 updaten

Hin und wieder müssen wir auch mal eine der Kernkomponenten des Systems auf eine neue Version upgraden, nicht nur unsere Anwendungen.

Die Datenbank ist so ein Fall.
Wir bringen MariaDB von Version 10.4 auf die neue Version 10.5
Präferiert ohne Datenverlust.

Packen wir’s an :)

Für dieses Upgrade ist unser Server gute 10 bis 20 Minuten offline, je nachdem, wie viele Dienste und Anwendungen auf die Datenbank zugreifen und mit umgestellt werden müssen. Daher empfehle ich die Umstellung spät Nachts, wenn am wenigsten auf unserem Server los ist.

Bitte mach zur Sicherheit vorher ein Backup aller Datenbanken. Oder noch besser einen Snapshot des gesamten Servers – wenn nicht jetzt, wann dann?

Wie genau wir das Update machen, hängt auch ein wenig davon ab, was wir auf unserer Maschine am Laufen haben. Am Sichersten finde ich, das komplette System stillzulegen, die Datenbank-Daten zu kopieren, die neue Datenbank zu starten und dann die Dienste nach der Anpassung an die neue Version einzeln wieder hochzufahren. Schauen wir uns den Prozess mal im Überblick an:

Die Schritte zum Datenbank-Update

  • Backups / Snapshot machen; derweil einen Bottich Kaffee trinken.
  • Neue „MariaDB v10.5“ docker-compose.yml schreiben und das Image davon ziehen lassen.
  • Auf dem Host den mariadb-client auf v10.5 upgraden.
  • Anwendungen und Dienste stoppen, die auf die Datenbank zugreifen.
  • MariaDB v10.4 Datenbankserver stoppen.
  • Datenbank-Verzeichnis kopieren.
  • MariaDB v10.5 Datenbankserver starten.
  • In den Container unserer MariaDB v10.5 teleportieren und dort das „mysql_update“ Script laufen lassen.
  • Alle Anwendungen, die unsere Datenbank benötigen: docker-compose.yml Datei anpassen. Eventuell auch Anwendungs-Configs umstellen.
  • Testen, ob wieder alles da ist, wo es hingehört. Scripts anpassen.
  • Sich freuen und „es lebt“ rufen…

Gut, gut… So sollte das funzen. Dann im Detail:

Backups / Snapshot machen; derweil einen Bottich Kaffee trinken

Wie besprochen ziehen wir *immer* ein Backup, bevor wir größere Umstellungen am System vornehmen!

Gut, dieses Mal ist es übertrieben, weil wir das Datenbank-Verzeichnis sowieso umkopieren und mit dem neuen weitermachen… Aber man hat ja bekanntlich schon Kuh-Mist auf Dächern gefunden. Und lieber hab ich die Daten doppelt und dreifach gesichert, als dass mir auf einmal ein Backup fehlt. Diese Datenbank-Daten sind immerhin der Kern – das Herzstück – unserer Anwendungen. Ohne die Datenbank ist zum Beispiel unsere Nextcloud nur eine Wolke voll mit Datenmüll. Vergessen wir das nie…

Backups sind im Backup-Tutorial beschrieben. Wenn wir ganz auf Nummer Sicher gehen wollen, fahren wir einen Snapshot von unserem Server.

So lange die Sicherungen laufen haben wir Zeit, unser System mit lebenswichtigem Kaffee zu fluten, damit wir die kommende Umstellung auch körperlich und mental packen.

Neue „MariaDB v10.5“ docker-compose.yml schreiben und das Image davon ziehen lassen

Na denn, legen wir los!

Da sich im Prinzip an der docker-compose.yml nicht viel ändert, kopieren wir diese einfach um und ändern in der Kopie ein paar Zeilen:

cp -a ~/docker/maria104master ~/docker/maria105master
nano ~/docker/maria105master/docker-compose.yml
### Das Image auf 10.5, klar. Dann die Verzeichnisse auf "105" umstellen. Und - ganz wichtig - den Namen des Dienstes auch auf "105" anpassen:
 maria105master:
  image: mariadb:10.5
  restart: unless-stopped

  volumes:
   - /var/maria105masterdata:/var/lib/mysql
   - /root/docker/maria105master/conf:/etc/mysql/mariadb.conf.d

restart: „unless-stopped“ ist das neue „always“

Beim Werken mit den Configs ist mir aufgefallen, dass der Restart-Typ „unless-stopped“ als Standard deutlich besser passt als „always“, den ich bis jetzt verwendet habe.
Warum?
Wenn wir wie hier mit zwei Datenbankservern parallel arbeiten und einen davon bewusst herunterfahren, startet uns Docker nicht versehentlich beide Server bei einem Restart oder falls wir mal nicht aufpassen. So lange wir den Dienst aber nicht händisch gestoppt haben, wird er auf jeden Fall bei einem Reboot wieder gestartet, ganz genau so wie bei „always“. Also hat „unless-stopped“ eigentlich nur Vorteile :)

Nun ziehen wir das neue Image, damit der Start danach schneller geht:

docker-compose -f ~/docker/maria105master/docker-compose.yml pull

Anzeige *

2 Kommentare zu „MariaDB von 10.4 auf 10.5 updaten“

  1. Guten Abend Peter,
    ich hoffe wir hören von Dir – gerade in der Coronazeit – ein wenig.

    FYI: Ich habe jetzt Traefik 2.3 in einem Step hochgezogen, ohne Probleme. Wichtig: alles genau lesen!

    Bei Deinem Datenbank Update ist mir folgendes schon aufgefallen, wo Du ursprünglich die Datenbank in Version 10.4 installiert hast. Die Versionsnummern sind bei Dir hart verdrahtet. Ich habe da eine Idee, die eigentlich gehen könnte.

    Du installierst alles z.B. nach ~/docker/maria104master
    Danach machst Du aber einen Symlink: ln -s ~/docker/maria104master ~/docker/mariadbmaster
    In den ganzen YAML Dateien gibst Du dann immer diesen Pfad an: ~/docker/mariadbmaster

    Wenn dann das Update auf die 105 kommt, brauchst Du nur den Symlink einmal löschen und mit dem neuen Pfad erzeugen lassen. Die ganzen YAML Config Datei bleiben unberührt. (Soweit die Theorie)

    Noch eine Frage: Kann man das Datenbank Update nicht auch direkt vom Host laufen lassen. Da ist doch der neue Client auch installiert?

    1. Was die wenigsten wissen, dass ich im „Haupterwerb“ eine Cocktailbar betreibe. Und die fällt mir zu Corona-Zeiten mächtig auf die Füße und ich muss ackern wie ein Besessener, um das Ding im Leerlauf halten zu können. Ich komm momentan auf eine 70 – 80 Stunden Woche. Selbst und Ständig… Daher hab ich während Corona leider so gut wie gar keine Zeit, nebenbei mit dem Stack zu spielen.

      Der Symlink ist eine gute Idee, das muss ich auf dem Testserver einfach ausprobieren.
      Alternativ hab ich mir die Variablen in der docker-compose.yml genauer angesehen. Da könnte was gehen. Aber das Setup, das ich will, ist natürlich wieder behaftet mit diversen Workarounds und anderen Schikanen :/
      https://docs.docker.com/compose/environment-variables/
      Aber wenigstens die ständige Neubenennung der Router von Traefik kann man damit elegant lösen…

      Du hast recht: Das könnte man auch über den Host machen. Haha, da war ich schon so drin, dass ich komplett vergessen hab, dass ich mich damals auch aus genau dem Grund für eine „Zentraldatenbank“ entschieden hab. Silly me…
      Andererseits hat das Werkeln direkt im Container nicht geschadet. Da war ich dann schon einigermaßen fit, als das bei Nextcloud spruchreif geworden ist.

      Aber ich seh schon: Es ist noch viel zu tun ;)

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top