Oft kann ich nicht über Computerkram berichten, da sich dabei immer wieder Interessenkonflikte mit meinem Arbeitgeber abzeichnen. Aber hier ist seit langem wieder mal etwas worüber ich schreiben kann.
Ich betreue einige Zammad – Installationen (self hosted). Einige Installationen sind aus dem Jahr 2018. Damals habe ich Zammad öfter mit Apache und MySQL betrieben.
Damals war mein Know-How für MySQL und Apache besser als für PostgreSQL und NgninX.
Ich habe mir schon länger vorgenommen eine meiner größten Zammad-Installationen auf die PostgreSQL zu migrieren. (wird von Zammad auch bevorzugt)
Wenn ein Datenbank-Wechsel erfolgreich durchgeführt werden kann, so soll dann auch der Webserver von Apache zu Nginx gewechselt werden. Da das Ausgangssystem damals noch unter Debian 9 betrieben wurde, wollte ich die Debian Version auch auf 10 heben. (Debian 11 gab es zu diesem Zeitpunkt schon, aber noch keine Zammad-Installation)
Diese Informationen haben mir geholfen, die Datenbank zu wechsel, stellt aber keine Garantie dar, dass diese Anleitung bei allen Zammad – Installationen funktioniert. Ich kann auch keine Unterstützung bei Problemen liefern.
Ich habe diese Schritte mehrfach getestet und für meine Fälle für ausreichend gut befunden, bevor ich ein großes Zammad-System migriert habe.
Einige Tests im Vorfeld zeigten, dass es weniger Probleme gibt, wenn die zu migrierende Datenbank möglichst kein ist. Aus diesem Grund wurde der Zammad-Datenspeicher von SQL auf File um konfiguriert und die bereits in der Datenbank abgelegten Attachments ins Filesystem übertragen.
zammad run rails r "Store::File.move('DB', 'File')"Da es sich bei diesem Vorhaben nicht um eine kleine Änderung im System handelt, war es mir wichtig immer wieder auf den alten Stand zurück wechseln zu können.
Das alte Zammad wurde daher in den Wartungsmodus versetzt, ein Zammad-Backup durchgeführt und die Backupdaten auf den neuen Server (Debian 10) kopiert. Danach wurde das alte System heruntergefahren und das neue System mit der gleichen IP-Adresse und dem gleichen Hostnamen konfiguriert wie das alte System.
Von diesem Zeitpunkt an würde ich das neue System ausschalten können und das alte System wieder einschalten, und könnte bei Problemen von neuem Beginnen oder mit dem alten System weiterarbeiten.
Meine Debian – Server – Installation versuche ich immer möglichst klein zu halten. (nur Debian Standard-Tools im Experten-Modus mit Sudo-Zugriff) Folgende Pakete wurden dann nachinstalliert (persönliche Vorlieben)
sudo apt install postfix ntp ncdu logcheck htop debian-goodies curl wget cron-apt gnupg2
Die Konfiguration der Einzelnen Pakete soll hier nicht beschrieben werden und haben mit dem eigentlichen Thema des Datenbank-Wechsels nichts zu tun, werden aber benötigt.
Das Zammad-System (Version 4.1.) am neuen Server wurde wie in den Zammad – Dokus installiert. Dabei wird Zammad mit NginX und Postgres installiert und konfiguriert.
Zammad könnte nun Konfiguriert werden, aber ich wollte die Daten aus dem alten System übernehmen.
Der Konfigurationswizard unter First Steps wurde NICHT ausgeführt, sondern zammad gestoppt.
sudo systemctl stop zammad
Damit die MySQL-Daten dann in die PostgreSQL übernommen werden können wurde ein MariaDB-Server zusätzlich zur PostgrSQL installiert (Zammad wurde bei der Installation für Postgres kofiguriert. Diese Konfiguration wird nicht geändert.)
sudo apt install mariadb-server
Ein zusätzlicher Root-User wurde in der MariaDB angelegt. (Infos) Natürlich sollte nicht das hier angegebene Passwort verwendet werden.
sudo mysql
grant all on *.* to root2@localhost identified by 'geheim' with grant option;
CREATE DATABASE zammad;
quit;
Der MySQL Datenbank-Dump der alten Zammad-Installation (Backup) wurde in die MariaDB Zammad geladen.
zcat 2021mmddhhiiss_zammad_db.mysql.gz | mysql -uroot2 -p zammad
Tipp: um die Daten in der MariaDB und in Postgres zu verändern und zu betrachten, habe ich mir php7.3-fpm php7.3-mysql php7.3-pgsql installiert, nginx für php-fpm konfiguriert und adminer unter /opt/zammad/public/adminer abgelegt.
Das Postgres Zammad Passwort kann in der Datei /opt/zammad/config/database.yml ermittelt werden.
Mit adminer verbindet man sich zur PostgresDB zammad und löscht den Inhalt aller Tabellen (truncate).
Für die eigentliche Datenbank-Migration wird pgloader verwendet.
sudo apt install pgloader
pgloader braucht eine Datei, in der die Datenbank-Verbindungen und Optionen angegeben werden.
Eine Beispiel pgloaderinfo-Datei sieht so aus.
load database from mysql://root2:geheim@127.0.0.1/zammad into pgsql://zammad:pgsqlgeheim@127.0.0.1/zammad alter schema 'zammad' rename to 'public' with batch concurrency = 1;
Die letzte Zeile „with batch concurrency = 1;“ habe ich bei einer großen Datenbank-Migration benötigt, da sonst pgloader bei der Konvertierung und Laden der Daten in die PostgreSQL mit Fehlern wie „Heap exhausted during garbage collection“ sich beendet.
pgloader --dry-run pgloaderinfo
Überprüft die Verbindungseinstellungen, versucht aber keine Daten zu transportieren. Werden hier keine Fehler angezeigt, so können die Daten (hoffentlich) ohne Fehler von der MySQL/MariaDB zur PostgresDB übertragen werden.
pgloader pgloaderinfo
versucht nun die SQL-Datenbank zu migrieren.
Sollten hier Fehler angezeigt werden, muss davon ausgegangen werden, dass Zammad nicht mit der PostgresSQL-Datenbank funktionieren wird. Warnungen über gekürzte Beschreibungsfelder dürften keine Probleme verursachen.
Hat bisher alles geklappt, sollte der Rest einfach funktionieren.
Die MariaDB wird nun nicht mehr benötigt und kann gestoppt und deaktiviert werden.
sudo systemctl stop mariadb
sudo systemctl disable mariadb
Aus dem Filebackup müssen einige Dateien wiederhergestellt werden.
Dazu entpackt man die tar -xzf 2021mmddhhiiss_zammad_files.tar.gz in einem Arbeitsverzeichnis und kopiert die Daten vom storage-Verzeichnis und public/assets/images in die Verzeichnisse der Zammad-Installation.
cd opt/zammad
sudo cp -r storage /opt/zammad/
sudo chown -R zammad:zammad /opt/zammad/storage/
cd public/assets/images
sudo cp -r * /opt/zammad/public/assets/images
sudo chown -R zammad:zammad /opt/zammad/public/assets/images
Nun sollte alles so weit vorbereitet sein, das Zammad gestartet werden kann.
sudo systemctl start zammad
Falls Zammad noch nicht an die Elastcsearch angebunden wurde, sollte das nun nachgeholt werden
sudo -u zammad zammad run rails r "Setting.set('es_url', 'http://localhost:9200')"Der Cache von Zammad sollte nun ebenfalls gelöscht werden, andernfalls gibt es seeeeeeeeehr unschöne Darstellungsprobleme in Zammad.
sudo -u zammad zammad run rails r Rails.cache.clear
Und dann möchte man natürlich auch noch, dass die Inhalte von Zammad in der ElasticSearch aktuell sind, daher sollte der Index neu erzeugt werden.
sudo -u zammad zammad run rake searchindex:rebuild
Nun sollte Zammad ausgiebig getestet werden und das Logging auf Probleme geprüft werden.
Bei meiner Migration gab es Probleme mit den Rollenzuordnungen. Diese wurden ein mal neu gesichert und funktionierten dann auch ohne Probleme.
Nach meinen Tests wurde Zammad 5 verfügbar.
Dieses Upgrade von 4.1 auf 5.0 (und dann 5.0.1) hat mit meiner migrierten PostgresDB ohne Probleme funktioniert.
Fazit: Die Tests und verschiedenen Migrations-Möglichkeiten von MySQL zu Postgres haben einiges an Zeit verschlungen. Aber mit den genannten Schritten konnte ich meine Installationen erfolgreich migrieren.
