System Migration (4/5) hängt in Endlosschleife fest

[Jan Eckhardt]

Hallo,

nachdem ich alle weiteren Probleme aus dem Weg geräumt habe, stecke ich jetzt bei Schritt 4/5 fest.

Mein Zielsystem: Ubuntu 20, Otobo 10
Mein Herkunftssystem: CentOS8, OTRS 6

 

Ich weiß nicht, was ich noch tun soll, denn bei der System Migration 4/5 fängt das Tool bei 3/104 an und endet bei 4/104, wobei kurz dann nach über 20 Minuten pro schritt nichts passiert und er dann von vorne durchläuft.

Was kann ich tun?

 

EDIT

Als Zusatz:

Ich habe gerade beobachtet, wie die Migrationsseite für nur wenige Sekunden angezeigt hat, dass die Verbindung temporär unterbrochen wurde, und dass sie automatisch neu geladen wird.

• This topic was modified 2 years, 3 months ago by Jan Eckhardt.

[gawkla gawkla]

Hello. I have meet similar issue. Did you resolve it?

Is there any log produced by migration.pl script or is there manual migration procedure? It would be great to see more verbose output what causing this issue.

• This reply was modified 2 years, 2 months ago by gawkla gawkla.

[hilocz]

Haben Sie die letzte Version ?

[gawkla gawkla]

OTRS not but almost tle last one, OTOBO is newest possible. Is there any log where I can try to find what is wrong?

[Jan Eckhardt]

Hallo hilocz,

Ich habe das Otobo 10.0.9 (aktuell vom jetzigen Datum ausgehend).
Das OTRS ist 6.0.30 (die OTRS FTP Server sind down, interessante Info am Rande)

Die Datenbank, die ich migrieren möchte, ist mehrere GB groß.

Ich habe ein neues und leeres OTRS 6 aufgesetzt und versucht zu migrieren. Nachdem ich die MySql Verbindung von dem Ubuntu 20 Server mit Otobo 10.0.9 herstellen konnte, hat die Migration der leeren OTRS Datenbank sofort und reibungslos geklappt.

In der jetzigen Live-Datenbank sind jedoch circa 2650000 Tabellen und entsprechende Anhänge. Der Prozess bricht aber selbst nach Reduzierung der Anhänge immer wieder ab. Es gibt leider keinerlei Fehlerberichte.

Ich werde noch probieren unsere vollständige Datenbank mit dem vollständigen Satz der Artikel (Attachments/Anhänge) zu migrieren, da ich tatsächlich die Artikel teilweise aus Testgründen gelöscht habe.

Man sieht hier auf dem Screenshot gut, dass es immer wieder zu einem Verbindungsabbruch kommt. Nach ca. 15 Sekunden startet alles noch einmal von vorne automatisch. Ich konnte gerade noch ein Screenshot machen.

Außerdem sieht man im Hintergrund, dass er nach ca 49 Sekunden den 5. Schritt terminiert. Schritt 1-2/104 wurden nie sichtbar aufgeführt. Für Schritt 3&4/104 hat das System jeweils ca. 20 Minuten gebraucht, nur um dann in Schritt 5/104 alles zu beenden und neu zu starten.

Ich komme leider noch auf keine Lösung.

 

Ich bedanke mich für jede Hilfe hierbei!

[Jan Eckhardt]

Ich habe die Vollständige Datenbank und alle articles jetzt in das OTRS 6 System hineingetan. Das OTRS 6 an sich funktioniert auch. Sprich, das sollte alles stimmen. Ebenfalls ist es im Wartungsmodus zum Zeitpunkt des Migrationversuchs.
Allerdings persistiert der Fehler, dass ab Schritt 4 zu 5 sofort ein Timeout zum Abbruch führt. Es gibt keine Fehlermeldung, anders, als dass nach ca 10 Sekunden die Seite automatisch neu geladen wird. Entsprechend ist es mir unmöglich, leider, auf OTOBO umzusteigen, da die Migration leider nicht funktioniert. Unglücklicherweise weiß ich auch von keinen weiteren Fehlerquellen oder Möglichkeiten an Error-Logs zu kommen, um das weiter zu analysieren.

[Sven Oesterling]

Hallo Herr Eckhardt,

könnten Sie bitte einmal mit einem

less /var/log/apache2/error.log

falls Sie kein Docker nutzen und das System standardmäßig mit dem apache2 aufgesetzt haben, und in dem Fall dass Sie Docker nutzen mit

docker logs otobo_web_1

gucken, ob Sie nicht doch Fehler sehen – da müssen fast sicher welche auftreten.

Viele Grüße, Sven

[Jan Eckhardt]

Ich habe zwei Bilder angefügt zu dem Errorlog.

 

Als die Meldung des Timeouts kam, die ich schon in einem Screenshot in einem oberen Post hochgeladen habe, habe ich einfach die Meldung weggedrückt. Bislang läuft die Migration weiter. Ist das normal, dass sie so lange braucht, oder liegt das an dem Volumen meiner DB + Article?

Da steht im errorlog nur etwas von der Notiz, dass Dinge auf 190 Zeichenlänge beschnitten werden.

 

 

Liebe Grüße

[Sven Oesterling]

Hallo Herr Eckhardt,

mir war nicht bewusst, dass das soo lange dauert. (Das ist durchaus realistisch, bei großen Systemen, je nach Datenbankperformance und Verbindung und so.)

Eine weitere Möglichkeit hier wäre aus dem otobo-Ordner (muss nicht installiert sein, glaube ich, sollte auch einfach auf dem otrs-System abgelegt werden können, falls es hilft) folgendes auszuführen:

scripts/backup.pl -t migratefromotrs --db-name otrs --db-host 127.0.0.1 --db-user otrs --db-password "secret_otrs_password"

Dabei müssen die Verbindungsdaten für die OTRS-Datenbank angepasst sein. Das erzeugt ein Satz an sql-Dateien, die auf dem otobo-System dann manuell via

mysql -uotobo -p otobo < datei.sql

eingespielt werden können. (Die Reihenfolge ist 1. pre, 2. schema_for_otobo, 3. data, 4. post. Das muss im Prozess genau an der Stelle passieren, bevor man auf otobo/migration.pl geht. Vermutlich würde es in Ihrem angefangenen System trotzdem auch noch funktionieren.) Wenn die Migration dann von vorne begonnen wird, kann in Schritt zwei, bei der OTRS-Datenbank die Checkbox „Skip DB Migration“ angehakt werden. Das teilt dem System mit, dass die Datenbank händisch eingespielt wurde, und die entsprechenden Schritte werden später übersprungen.

Versuchen Sie das am besten auch nochmal auf einem Testsystem. Sollten Sie nicht weiterkommen, können Sie sich für professionelle Unterstützung auch gerne unter hallo@otobo.de an uns wenden.

Viele Grüße, Sven

• This reply was modified 2 years, 2 months ago by Sven Oesterling.

[Jan Eckhardt]

Ich habe das Script ausgeführt, allerdings scheinen Rechte zu fehlen. Welche Rechte müssen dafür genau gesetzt sein? Bislang hat alles auf alles zugriff in meiner Testumgebung.

 

[Sven Oesterling]

Nein, da ist der Aufruf falsch – das sind sql-Dateien, die können nicht ausgeführt werden, sondern müssen, wie oben beschrieben quasi in die entsprechende OTOBO-Datenbank eingelesen werden:

mysql -uotobo -p otobo < otrs_pre.sql

(Da wird dann das Passwort für die OTOBO-Datenbank abgefragt.)

[Jan Eckhardt]

Vielen Dank für den Support.

Mit dieser Methode war es mir möglich das OTRS System nach OTOBO zu migrieren. Bis auf die Mail Einstellungen scheint auch alles übernommen worden zu sein. Den Mailerhalt und Versand kann ich dann jetzt testen.

 

Liebe Grüße

Jan

[Jan Eckhardt]

Hallo noch einmal!

Ich bin nun beim Implementieren des OTOBOS in unser betriebliches Live-System.

Bei der Migration, die ich händisch mit der oben aufgeführten Anleitung durchführen wollte, stieß ich auf einen Fehler. Ich bin leider noch nicht dahinter gekommen, was das Problem war.
Was könnte ich tun?

 

[Sven Oesterling]

Hallo,

das ist eine unvollständige Antwort, ich hab grad leider keine Zeit das genau nachzuvollziehen, aber zumindest als schnelle Info: Von dem Problem wurde uns erst vor ein paar Tagen schoneinmal berichtet, die Lösung war, dass dem mysqldump aus dem script wohl ein zusätzlicher Parameter mitgegeben werden muss, bei einer bestimmten mysql-Version. Genaueres weiß ich darüber aber leider nicht. Vielleicht hilft es ja trotzdem, ansonsten wird das so bald wie möglich gefixed.

Viele Grüße, Sven

[Jan Eckhardt]

Danke für die Antwort. Ich werde schauen, ob es dort etwas herauszufinden gibt.
Über einen fix würde ich mich sehr freuen – oder ein Update welcher Parameter es genau sei. :)

• This reply was modified 2 years, 2 months ago by Jan Eckhardt.

[Jan Eckhardt]

Ich habe das Migrationstool noch einmal benutzt ohne die Datenbank mit dem Befehl zu dumpen, was ja leider nicht klappt.
Jetzt komme ich zu dem 6. Schritt, wo vorher mit dem kleineren Test System die Migration bei dem 5. Schritt feststeckte. Allerdings, auch hier, tritt der Timeout wieder in Kraft.

Leider kann ich das System nicht migrieren.

[Sven Oesterling]

Hallo Herr Eckhardt,

bei dem besagten anderen Fall hatte es geholfen die mysql config anzupassen und im Abschnitt [mysqldump]

column-statistics=0

zu setzen. https://github.com/RotherOSS/otobo/issues/884

Ich hoffe das hilft, Sven

[Jan Eckhardt]

Danke für die Hilfe, Sven!

Das hat geklappt und die Migration hat so jetzt manuell funktioniert.

 

Ich bedanke mich. Für alle weiteren Fragen würde ich ein neues Thema aufmachen.

 

Gruß

Jan

[Author]

Posts