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

Haftungsausschluss / Disclaimer

MariaDB von 10.4 auf 10.5 updaten

Alle Anwendungen, die unsere Datenbank benötigen: docker-compose.yml Datei anpassen. Eventuell auch Anwendungs-Configs umstellen

In allen docker-compose.yml Dateien unserer Anwendungen steht noch die Referenz auf „maria104master“ drin. Diese müssen wir jetzt Dienst für Dienst auf die „105“ ändern und die Anwendung danach starten. Bei manchen geht das schnell und einfach, bei einigen müssen wir zusätzlich noch Config-Dateien in den jeweiligen Anwendungs-Verzeichnissen anpassen…

Wichtig! Ich kann nicht hellsehen und bei Dir heißen die Verzeichnisse sicher anders. Diese musst Du natürlich auf Deine Gegebenheiten hin abändern…

phpMyAdmin

Hier ändern wir nur die docker-compose.yml:

nano /var/www/phpmyadmin/docker-compose.yml

  environment:
   PMA_HOST: maria105master
  external_links:
   - maria105master

Änderungen speichern. Wir lassen den Dienst ausgeschaltet, bis wir wirklich Änderungen an den Datenbanken vornehmen möchten.

WordPress

Hier ist ebenfalls nur eine Änderung der docker-compose.yml nötig:

nano /var/www/wordpress/docker-compose.yml

  environment:
   WORDPRESS_DB_HOST: maria105master:3306
  external_links:
   - maria105master

Wir speichern die Änderungen und starten den WordPress Container mittels

docker-compose up -d

Nun sollte die WordPress Seite wieder laufen…

Matomo

Bei Matomo ändern wir die docker-compose.yml und eine Config-Datei von Matomo:

nano /var/www/matomo/docker-compose.yml

  external_links:
   - maria105master

nano var/www/matomo/wwwdata/config/config.ini.php

[database]
host = "maria105master"

Wir speichern die Änderungen und starten den Matomo Container mittels

docker-compose up -d

Unser Statistik-Tool dürfte jetzt wieder am Start sein ^^

Nextcloud

Bei Nextcloud ändern wir wie bei Matomo die docker-compose.yml und eine Config-Datei innerhalb von Nextcloud:

nano /var/www/nextcloud/docker-compose.yml

  environment:
   MYSQL_HOST: maria105master:3306
  external_links:
   - maria105master

nano /var/www/nextcloud/wwwdata/config/config.php

  'dbhost' => 'maria105master:3306',

Wir speichern die Änderungen und starten den Nextcloud Container mittels

docker-compose up -d

Und schon sollte unsere Cloud wieder laufen…

Haben wir alle Dienste wieder am Start? Dann schauen wir, was Docker dazu meint:

Testen, ob wieder alles da ist, wo es hingehört. Scripts anpassen

Mit einem schnellen „docker ps -a“ prüfen wir, ob alle Dienste wieder oben sind und laufen.

Was wir noch machen müssen ist, die beiden Scripts „upup-docker“ und „update-docker“ zu ändern. Diese stellen wir auch auf die „105“er Verzeichnisse um:

nano upup-docker.sh
### MariaDB 10.5 Master durchstarten
/usr/bin/docker-compose -f /root/docker/maria105master/docker-compose.yml up -d

nano update-docker.sh
### MariaDB
docker-compose -f ~/docker/maria105master/docker-compose.yml pull

Alles sauber am Start?
Dann machen wir gleich ein Vollbackup, um unsere Änderungen zu sichern:

~/backup-all.sh

Und damit ist der Umstieg von MariaDB v10.4 auf v10.5 abgeschlossen :)

Sich freuen und „es lebt“ rufen…

Bleibt der obligatorische Freudentanz, die Tränen der Rührung abzuwischen und *ES LEBT* zu schmettern. Damit haben wir erst mal einige Zeit Ruhe, bevor wir das Spielchen für v10.6 wiederholen dürfen.

Ich behalte aus sentimentalen Gründen die „~/docker/maria104master“ und „/var/maria104masterdata“ noch gute vier Wochen und bin wachsam, ob *wirklich* alles sauber läuft. Gab es keine Vorkommnisse, lösche ich nach dem Zeitraum beide Verzeichnisse.
Bitte aufpassen, dass wir wirklich „104“ und nicht aus Versehen das „105“er von der Platte putzen, wenn es so weit ist ^^

Fazit

An und für sich ist der Umstieg auf die nächste Version der Datenbank nicht tragisch.

Und wir haben ja ein Netz – bzw. einen doppelten Boden – in Form der „104“er Verzeichnisse, die wir erst mal behalten. Sollten alle Stricke reißen, kehren wir zu v10.4 zurück. Aber das dürfte nicht nötig sein…

Nachtrag 13.07. / Zuckerl: Suchen/Ersetzen Script

Es stimmt wirklich, dass Admins lieber eine Stunde basteln, um einen Job zu automatisieren, der ansonsten eine Minute gedauert hätte, weil sie effizient sein wollen. Und Sachen nicht repetitiv doppelt und dreifach eingeben möchten.

Ich präsentiere… Trommelwirbel… Tusch!

Das „Suchen und Ersetzen“-Script, das in allen docker-compose.yml Dateien unterhalb von /var/www den String „maria104master“ in „maria105master“ ändert:

find /var/www -maxdepth 2 -type f -exec sed -i 's/maria104master/maria105master/g' {} \;

Wir verketten hier zwei Befehle, „find“ und „sed“. Mit „find“ schaffen wir eine Liste an Dateien, die dann von „sed“ durchkämmt und geändert werden.

find – der Befehl „find“.
/var/www – das Verzeichnis, von dem aus gesucht wird.
-maxdepth 2 – die Tiefe, wie tief „find“ die Unterverzeichnisse durchackert. 1 wäre nur das /var/www, 2 sind alle Unterverzeichnisse innerhalb von /var/www.
-type f – nur reguläre Dateien.
-exec – die Übergabe der Dateiliste an das Folgeprogramm.

sed – der Befehl „Stream EDitor“.
-i – schreibt Änderungen in die Datei. Ohne „-i“ wird die geänderte Datei nur angezeigt. Gut zum Testen!
’s/maria104master/maria105master/g‘ – ’s/SUCHEN/ERSETZEN/g‘.
{} \; – in die geschweiften Klammern postet „find“ jetzt die Dateinamen mit Pfad, die von „sed“ geändert werden sollen.

Führ das Script bitte einmal zum Testen ohne das „-i“ aus und überprüfe die Bildschirmausgabe. Sollte alles gut sein, noch mal mit „-i“, dann werden die Dateien neue geschrieben…

Je mehr Unterverzeichnisse wir in /var/www haben, desto mehr Spaß macht das Script natürlich :)
Also, haut rein!


Wie angekündigt gehe ich jetzt mit dem Blog in „Corona-Pause“ und bringe nach der Anpassung aller Artikel auf die MariaDB v10.5 fürs erste nur noch Update-Meldungen. Hoffen wir, dass der Blödsinn bald vorbei ist, dann wecke ich „Projekt Rootserver“ wieder aus seinem Dornrößchen-Schlaf… Viel Glück euch allen – und haltet die Ohren steif!

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