Schlagwörter: 

Ansicht von 4 Antwort-Themen
  • Autor
    Beiträge
    • #32088
      Joachim Wiest
      Teilnehmer

        Hallo,

        ich möchte von folgendem System:

        OTRS 6.03 / PostgreSQL 9.5.25 auf Ubuntu Server

        Auf Otobo 10.1 (Docker Installation) migrieren.
        Es hat bis zu diesem Schritt auch alles nach Anleitung funktioniert
        (https://doc.otobo.org/manual/installation/10.1/de/content/migration-from-otrs.html)

        Nur dann kommt bei der System Migration immer bei Copy Table “article_data_mine_Attachment” nach ca. 1-2 Minuten diese Meldung. Wenn man auf Seite aktualisieren klickt kommt man zurück zum “Migration starten” Button. Wenn man “Diesen Dialag schließen” klickt, scheint es weiter zu gehen. Es läuft aber nur die Zeit weiter. Daten werden nicht mehr übertragen.
        Vor der Meldung werden bei uns mit ca. 400-500MB/s Daten kopiert, kurz vor der Meldung geht das auf 0 MB/s zurück.

        Was kann ich hier tun ?
        Verschiedene Browser habe ich versucht, Quell-OTRS-System auch schon neu gestartet.

         

      • #32094
        Stefan Rother
        Administrator

          Hallo Joachim,

          ich denke mal es ist irgendein Proxy dazwischen, der die Verbindung irgendwann kappt, oder es tritt irgendein anderes Problem auf.

          Zuerst würde ich im Logfile schauen, ob da irgendwas verwertbares steht, was mit dem Abbruch zusammen hängt:

          root> docker logs otobo_web_1 -f

          Wenn nicht, dann ist es normalerweise der Fall, dass die Migration weiterläuft, auch wenn die Verbindung im Browser gekappt wird. Dann einfach nur “Diesen Dialog schließen” klicken und weiter das Logfile beobachten. Wenn er die Tabelle xml_storage als fertig migriert ausgibt, ist der Task abgeschlossen und wenn Du die Migration dann erneut aufrufst, geht es mit dem nächsten Schritt weiter. Der Rest geht dann ganz schnell.

          Die Frage ist auch, wo liegt die Datenbank. Wenn uns da ein Proxy dazwischenfunkt, würde ich die DB lokal in die Docker MariaDB importieren (in eine eigene DB otrs). Wenn Du danach noch einen Abbruch bekommst, dann liegt es an der Strecke zwischen Deinem PC/Browser und OTOBO, die nach 60 Sekunden gekappt wird. Dann ist es aber wie gesagt nicht tragisch, so lange man den Task fertig laufen lässt.

          Wenn alle Stricke reißen, wir ( https://otobo.io ) bieten die Migration auch als schlüsselfertige Dienstleistung an.

          Ich hoffe ich konnte Dir weiterhelfen,

          Stefan Rother

          Team OTOBO

          • #32095
            Joachim Wiest
            Teilnehmer

              Hallo Stefan,

              es ist kein Proxy oder Firewall dazwischen.
              So bleibt es stehen. Ich habe es mehrfach versucht. Ab dieser Fehlermeldung werden keine Daten mehr übertragen und es kommen keine Einträge mehr dazu.
              Gibt es irgendeinen anderen Log den ich prüfen könnte ?

          • #32104
            Stefan Rother
            Administrator

              Hallo Joachim,

              ja hier liegen die großen Datenmengen und Dateien. Und da hier keine Fehlermeldung ist, glaube ich auch nicht, dass er wirklich abbricht. Wie stellst Du fest, das keine Daten übertragen werden? Das kann einfach dauern, bis diese angezeigt werden. Und wie groß ist die DB / Tabelle?

              Ansonsten die DB mal lokal in die Docker DB ziehen und von da migrieren, dann kannst Du sicher sein, dass nichts anderes dazwischen funkt.

              Schöne Grüße,

              Stefan

              • #32105
                Joachim Wiest
                Teilnehmer

                  Guten Morgen Stefan,

                  die Datenbank hat 60GB.

                  Hier die großen Tabellen:
                  article_data_mime_plain = 33GB
                  article_data_mime_attachment = 24GB

                  Die restlichen Tabellen haben unter 1GB

                  Ich habe mit ifstat die Datenübertragung beobachtet. Da sehe ich eben, dass es kurz vor der temp. Verbindungsunterbrechung Meldung im Browser auf 0MB/s einbricht. Vorher sind es ca. 200-500MB/s. Danach bleibt es auch auf 0MB/s, auch wenn ich lange warte.

                  Ich versuche mal deinen Tipp. Muss nur noch herausfinden wie ich die Postgresql DB lokal in den Docker bekomme ;-)

                  Danke

              • #32106
                Stefan Rother
                Administrator

                  Hallo Joachim,

                  das klappt nicht lokal in Docker, denn da läuft eine MariaDB. :(

                  Ich denke das Problem liegt dann an der PostgreSQL Konfiguration, aber mit Postgres kenne ich mich zu wenig aus. Ich würde mal Postgres auf Fehlermeldungen überprüfen.

                  Ein weiterer Workaround wäre (diesen Schritt würde ich generell irgendwann empfehlen), die Attachments von der DB in das Filesystem zu migrieren und auch dort in Zukunft zu speichern. Ansonsten wird die DB immer weiter wachsen, da die Attachments und Inline-Images immer größer werden. Somit sind die große Dateien raus und die Tabelle sollte keine Probleme mehr machen.

                  Vorgehen auf dem OTRS Server:

                  Bitte überprüfe das Du genug Speicherplatz auf dem OTRS Server hast, im Standard schreibt er die Artikel nach /opt/otrs/var/article (Der Pfad kann aber per Config geändert werden).

                  Dann in der OTRS Konfiguration per SysConfig oder in der Config.pm folgende Optionen setzen:

                  $Self->{'Ticket::StorageModule'} = 'Kernel::System::Ticket::ArticleStorageFS';
                  $Self->{'Ticket::StorageModule::CheckAllBackends'} = '1';

                  Anschließend folgendes Skript ausführen:

                  bin/otrs.Console.pl Admin::Article::StorageSwitch--target ArticleStorageFS --tolerant

                  –tolerant würde ich mit angeben, dann überspringt er korrupte Attachments.

                  Wenn alle Attachments auf dem Filesystem liegen, kannst Du diese Option wieder deaktivieren:

                  $Self->{'Ticket::StorageModule::CheckAllBackends'} = '0';

                  Die brauchen wir nur für die Zwischenzeit, wenn teilweise Daten in der DB und im FS liegen.

                  Die extrahierten Attachements könntest Du dann einfach bei oder nach der OTOBO Migration in den Docker Container an diese Stelle syncen, dann müssen diese nicht kompliziert über https übertragen werden:

                  /var/lib/docker/volumes/opt_otobo_opt/_data/var/article/*

                  Danach nur noch die Rechte setzen:

                  root> chown 1000:1000 /var/lib/docker/volumes/opt_otobo_opt/_data/var/article -R

                  Das würde ich wie gesagt sowieso machen und ich kann mir vorstellen, dass dadurch die Migration auch klappt.

                  Schöne Grüße,

                  Stefan

                • #32110
                  Joachim Wiest
                  Teilnehmer

                    Guten Morgen Stefan,

                    der Workaround hat funktioniert :)
                    Vielen Dank
                    Ich habe heute Nacht die Daten aufs Filesystem ausgelagert und die Migration heute durchlaufen lassen.

                    Danach habe ich mit folgendem Befehl die Dateien migriert und die Berechtigungen gesetzt.
                    rsync -avh /opt/otrs/var/article/ root@10.0.9.117:/var/lib/docker/volumes/otobo_opt_otobo/_data/var/article/

                    root> chown 1000:1000 /var/lib/docker/volumes/otobo_opt_otobo/_data/var/article -R

                    Jetzt sieht alles gut aus. Die Konfigurationen/Agenten/Tickets/Anhänge sind alle da.

                    Nur die Elasticsearch Suche geht nicht. Da kommen keine Ergebnisse. Muss man dazu noch irgendwas laufen lassen ?

                Ansicht von 4 Antwort-Themen
                • Du musst angemeldet sein, um auf dieses Thema antworten zu können.