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, 9 months ago by Jan Eckhardt.
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, 9 months ago by gawkla gawkla.
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 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.
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.
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, 8 months ago by Sven Oesterling.
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.
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.)
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.
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?
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.
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, 8 months ago by 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.
Our website uses cookies. Cookies are tiny text files which are saved in your web browser or by your web browser on your device when you access websites. They contain a characteristic character sequence allowing to clearly identify your browser upon your next visit to the website.
You can prevent the setting of cookies at any time by making the appropriate setting in your internet browser. Cookies that have already been set can be deleted manually or automatically at any time. This is possible in all common internet browsers. If the setting of cookies is deactivated in the browser, not all functions of the website may be fully usable.
We deliberately use very little cookies.
Detailed information can be found in section 4 of our Privacy Policy.
Necessary cookies
Essential Cookies are necessary to deliver this website and some of its features correctly.
For this reason, we do not provide any opportunity here to disable them.
Notwithstanding this, you can deactivate all Cookies in your Browser Settings at any time. Please be aware, however, that this might have an impact on the functionality of this website.
More information about the cookies to be set and how long they will be stored can be found in section 4 of our Privacy Poliy: Privacy Policy.
Google Analytics' Cookies
When you visit this website, Google Analytics sets cookies on your system. This will help us analyse how you use our website ans tailor it to the needs of our visitors. Your IP address will be automatically anonymised (IP anonymisation and deactivation of your User ID). Therefore, we cannot trace which data a certain user is accessing. The data are not saved together with any other personal user data.
You can deactivate tracking in your browser if you do not want us to be able to track your visit on our website.
Privacy Policy
Detailed information on the usage of cookies as well as our Privacy Policy can be found here: