-
Beiträge
-
-
Hallo,
Gestern habe ich versucht, die Produktionsversionen OTRS 6 Community Edition und OTOBO 10.1 (Docker) zu migrieren. Die Produktionsdatenbank befindet sich auf MySQL. Ich habe die Migration gestartet und nachdem alle Datenbanktabellen kopiert wurden, werden alle kopierten Tabellen gelöscht (ich habe dies in MariaDB im Container otobo-db-1 überprüft) und das Kopieren der Tabellen beginnt von vorne??
Ich kann nicht glauben, dass das passiert ist :O Ist das ein Witz?
In der Testumgebung (mit Testdatenbank) hatte ich jedes Mal eine erfolgreiche Migration. Ich weiß nicht, was hier passiert ist. Mir bleibt nur, das Skript migration.pl zu finden und es zu untersuchen, um zu sehen, was passiert ist. Kann jemand helfen?
Die Datenbank ist 38 GB groß.
In den Protokollen sind keine Fehler sichtbar.
-
-
Hallo AnteIde,
um die letzte Frage zuerst zu beantworten: Ist das Skript möglicherweise das hier? https://github.com/RotherOSS/otobo/blob/rel-10_1/bin/cgi-bin/migration.pl
Was die Datenbank angeht, um sicherzugehen, dass ich das richtig verstanden habe: Ist das Skript zweimal durchgelaufen? Ist es unterbrochen worden? Wie kann ich das reproduzieren?
Beste Grüße
Stefan -
Hallo Antelde,
nein, die Tabellen werden nicht alle gelöscht und es fängt automatisch von vorne an, dieses Verhalten hatte ich noch nie.
Ich denke auch nicht, dass es Dir weiterhilft die Skripte zu untersuchen (diese befinden sich unter Kernel/System/MigrateFromOTRS), aber ich glaube Du unterschätzt die Komplexität.
Wenn es im Testsystem funktioniert hat, dann würde ich überlegen was bei der Produktivmigration anders gelaufen ist. Wir migrieren jede Woche Systeme von OTRS zu OTOBO und verwenden auch die gleichen Skripte, die allen zur Verfügung stehen.
Ansonsten helfen wir auch gerne, machen die Migration für Euch, oder beantworten Fragen bei konkreten Problemen im Rahmen eines Supportvertrages.
Schöne Grüße,
Stefan
Team OTOBO
-
@Stefan Härter
Ich habe auch dieses Skript gefunden: https://github.com/RotherOSS/otobo/blob/rel-10_1/bin/cgi-bin/migration.pl, aber ich glaube nicht, dass es das ist, das wir brauchen. Es kümmert sich nicht um Aufgaben wie das Kopieren der Datenbank zwischen Servern, das Migrieren von Dateien von OTRS nach OTOBO oder andere notwendige Schritte.Zum Migrationsproblem:
Ich habe die offizielle Migrationsanleitung befolgt und das Skript ausgeführt. Anfangs schien es, als würde der Prozess beim Schritt „ticket_history“-Tabelle kopieren hängen bleiben. Das war jedoch mein Fehler – ich habe die falschen Parameter betrachtet und eine falsche Annahme getroffen. Der Prozess hat einfach nur länger gedauert.
Leider habe ich den otobo-db-Container zu diesem Zeitpunkt gestoppt, wodurch das Migrationsskript (wie zu erwarten) fehlgeschlagen ist. Anschließend hat ein Kollege die „ticket_history“-Tabelle gemäß folgender Anweisungen geändert:
- Alle article_id-Werte, die auf NULL gesetzt waren, wurden auf INT(0) geändert.
Wir werden dies rückgängig machen.
Ich habe das Migrationsskript neu gestartet, aber es schien von selbst abzubrechen. Der Button „Migration starten“ wurde wieder verfügbar. Ich habe das Skript ein drittes Mal gestartet, und nachdem alle Tabellen kopiert wurden, geschah etwas Ungewöhnliches – weniger als eine Minute später wurden die Tabellen laut Logs erneut von Anfang an kopiert.
Als ich das bemerkte, bin ich in den otobo-db-1-Container gegangen und habe festgestellt, dass die migrierte Datenbank leer war. Zum Beispiel:
MariaDB [otobo]> SELECT * FROM ticket_history ORDER BY id DESC LIMIT 1;
Empty set (0.000 sec)Das sind also die Schritte, um das Problem zu reproduzieren.
Ehrlich gesagt bin ich von diesem Verhalten überrascht. Die Dokumentation von OTOBO ist ausgezeichnet, daher habe ich solche Probleme nicht erwartet – und doch stehen wir jetzt hier. 😢
@Stefan Rother
Konntest du die angehängten Logs, das Migrationsprotokoll, schon überprüfen?Es scheint, dass die Tabellen erneut automatisch kopiert wurden – würdest du dem zustimmen?
Vielen Dank, dass du den Pfad zu den Skripten geteilt hast. Wie du erwähnt hast, scheinen sie recht komplex zu sein, und daher würde ich es vorziehen, nicht zu tief in sie einzutauchen.
Ich schätze deinen Rat, die Unterschiede zwischen der Test- und Produktionsdatenbankmigration zu vergleichen.
Zur Orientierung habe ich außerdem das vollständige Logfile angehängt.
Vielen Dank für deine Antworten und deine Unterstützung!
-
Hi,
für mich sieht es aus, als wurde der Cache gelöscht. Dann beginnt OTOBO wieder von vorne, wenn otobo/migration.pl neu aufgerufen wird.
Bei der Migration kann es vorkommen, dass die Verbindung im Browser beendet wird (wenn die Migration sehr lange dauert, oder es eine Netzwerkunterbrechung gibt, oder wenn ein externer Proxy verwendet wird).
Dann ist es das einfachste abzuwarten, bis im Log auch die Tabelle xml_storage fertig übertragen wurde. (mit „top“ oder „ps aux“ zusätzlich kontrollieren). Bis dahin einfach bitte NICHTS unternehmen, das Skript läuft im Hintergrund weiter.
Sobald dann der Datenbankteil erledigt ist, nochmal /otobo/migration.pl aufrufen (Es wird eine Meldung angezeigt, dass ein Cache existiert, diesen bitte NICHT löschen lassen).
Dann geht es sofort mit dem nächsten Punkt weiter und die Konfiguration wird migriert.
Und bitte dafür sorgen, dass nicht jemand anderes auch testet und migration.pl aufruft.
Dann sollte die Migration auch klappen.
Wenn nicht, wir bieten OTOBO Consulting und Support, um das System zuverlässig auf OTOBO zu migrieren und das kostet auch nicht die Welt, wenn man überlegt wie viele Lizenzkosten gespart werden.
Viel Glück!
Stefan
Team OTOBO
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.