Zarafa Upgrade(7.1.12):zarafa4ucs-migrate hängt bei contacts

pro4567 · May 7, 2015, 6:41pm

Habe gerade auf einem UCS 4.0.1 (vorher alle Erratas bis 193 installiert) auch Zarafa Update von 7.1.11 auf 7.1.12 angestoßen, jedoch hängt nun ansch. zarafa4ucs bei Migration der contacts:

130 root@bigpapa ~ # tail -f -n 20 /var/log/univention/management-console-module-appcenter.log                                                                                                                                                                              :(
07.05.15 19:32:03.043  MODULE      ( PROCESS ) : Changing externID for XXXXXXX from 2012 (uidNumber) to d8f746e2-7e35-1034-8f36-310b10688197 (entryUUID)
07.05.15 19:32:03.044  MODULE      ( PROCESS ) : Changing externID for XXXXXXX from 2013 (uidNumber) to 4ccb72b4-7e36-1034-8f3b-310b10688197 (entryUUID)
07.05.15 19:32:03.045  MODULE      ( PROCESS ) : Changing externID for XXXXXXX from 2014 (uidNumber) to b3638cc8-7e36-1034-8f40-310b10688197 (entryUUID)
07.05.15 19:32:03.045  MODULE      ( PROCESS ) : Changing externID for XXXXXXX from 2015 (uidNumber) to 52206dea-7e37-1034-8f45-310b10688197 (entryUUID)
07.05.15 19:32:03.047  MODULE      ( PROCESS ) : Changing externID for XXXXXXX from 2016 (uidNumber) to bab6ceee-7e37-1034-8f4a-310b10688197 (entryUUID)
07.05.15 19:32:03.048  MODULE      ( PROCESS ) : Changing externID for XXXXXXX from 2018 (uidNumber) to b6263178-7e3f-1034-8f54-310b10688197 (entryUUID)
07.05.15 19:32:03.049  MODULE      ( PROCESS ) : Changing externID for billing from 2019 (uidNumber) to 3f692624-811b-1034-8f5e-310b10688197 (entryUUID)
07.05.15 19:32:03.050  MODULE      ( PROCESS ) : Changing externID for info from 2020 (uidNumber) to 0627b9b0-811c-1034-8f63-310b10688197 (entryUUID)
07.05.15 19:32:03.051  MODULE      ( PROCESS ) : Changing externID for messe from 2021 (uidNumber) to 945f026e-8127-1034-8f68-310b10688197 (entryUUID)
07.05.15 19:32:03.052  MODULE      ( PROCESS ) : 
07.05.15 19:32:03.052  MODULE      ( PROCESS ) : Migrating shared stores and non-active users:
07.05.15 19:32:03.058  MODULE      ( PROCESS ) : Updating uid=billing,cn=users,dc=telequest-main,dc=local
07.05.15 19:32:03.072  MODULE      ( PROCESS ) : Moving uid=billing,cn=users,dc=telequest-main,dc=local to uid=billing,cn=non-active,cn=zarafa,dc=telequest-main,dc=local
07.05.15 19:32:03.076  MODULE      ( PROCESS ) : Updating uid=info,cn=users,dc=telequest-main,dc=local
07.05.15 19:32:03.079  MODULE      ( PROCESS ) : Moving uid=info,cn=users,dc=telequest-main,dc=local to uid=info,cn=non-active,cn=zarafa,dc=telequest-main,dc=local
07.05.15 19:32:03.086  MODULE      ( PROCESS ) : Updating uid=messe,cn=users,dc=telequest-main,dc=local
07.05.15 19:32:03.096  MODULE      ( PROCESS ) : Moving uid=messe,cn=users,dc=telequest-main,dc=local to uid=messe,cn=non-active,cn=zarafa,dc=telequest-main,dc=local
07.05.15 19:32:03.099  MODULE      ( PROCESS ) : 
07.05.15 19:32:03.099  MODULE      ( PROCESS ) : Migrating contacts:
07.05.15 19:32:03.529  MODULE      ( PROCESS ) : "my" variable %cache masks earlier declaration in same scope at /usr/share/zarafa4ucs/db-upgrade-addressbook-entryids-delegate.pl line 251.

Wir haben 3 shared stores user eingerichtet, diese wurden ansch. auch erfolgreich migriert.

Eventuell ist da doch noch ein Bug im Script? Kann ich diese Migration (ohne Folgen) wie abbrechen? Wie kann ich das korrekt, abschließen? Der Rest (Paket & Schemata Update) scheint laut (langem Log) schon korrekt durch zu sein, Webapp meldet sich mit Version WebApp 1.6-46049 - ZCP 7.1.12-48726 aber “Cannot connect to the zarafa server” beim Login-Versuch.

System wurde mit UCS 4.0.1 und Zarafa 7.1.11 erst vor kurzem frisch ausgesetzt, Daten migriert, sollte am WE produktiv gehen

Danke für jede Hilfe!
Rob

pro4567 · May 8, 2015, 8:58am

Anscheinend war ich nur zu ungeduldig, die Migration/Update ist nun ansch. doch korrekt (bisher nichts entdeckt) abgeschlossen worden, hat aber ca. 1,5h gedauert (DB ohne Attachments ca. 27GB groß, aber im Testbetrieb hatte die VM nur 4GB RAM). Die Ausgabe -auch in UMC- war für mich nur sehr irritierend, kein vernünftiger Fortschritts-Status, stattdessen nur die Perl-Script Warnung. Gut, dass ich nicht abgebrochen habe

So ging es im Log weiter:

07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 1 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 2 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 3 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 4 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 5 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 6 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 7 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 8 of 11 07.05.15 20:52:06.113 MODULE ( PROCESS ) : Converting properties table step 9 of 11 07.05.15 20:52:06.114 MODULE ( PROCESS ) : Converting properties table step 10 of 11 07.05.15 20:52:06.114 MODULE ( PROCESS ) : Converting properties table step 11 of 11 07.05.15 20:52:06.114 MODULE ( PROCESS ) : Converting rules... 07.05.15 20:52:06.114 MODULE ( PROCESS ) : Converting ruleset 1 07.05.15 20:52:06.114 MODULE ( PROCESS ) : Converting ruleset 2 07.05.15 20:52:06.114 MODULE ( PROCESS ) : Converting delegates... 07.05.15 20:52:06.114 MODULE ( PROCESS ) : Committing changes to database 07.05.15 20:52:07.278 MODULE ( PROCESS ) : Starting Zarafa LMTP dagent: zarafa-dagent. . .

und mit

07.05.15 20:54:21.364 MODULE ( PROCESS ) : Ersatz für zarafa-webapp wird entpackt ... 07.05.15 20:54:22.448 MODULE ( PROCESS ) : Ersatz für zarafa-webapp wird entpackt ... 07.05.15 20:54:23.500 MODULE ( PROCESS ) : zarafa-webapp (2.0.2.48619) wird eingerichtet ... 07.05.15 20:54:24.685 MODULE ( PROCESS ) : Restarting web server: apache2 ... waiting 07.05.15 20:54:25.715 MODULE ( PROCESS ) : Restarting web server: apache2 ... waiting 07.05.15 20:54:26.778 MODULE ( PROCESS ) : RUNNING 70zarafa4ucs.inst 07.05.15 20:54:27.861 MODULE ( PROCESS ) : EXITCODE=already_executed 07.05.15 20:54:28.931 MODULE ( PROCESS ) : EXITCODE=already_executed 07.05.15 21:04:31.236 MAIN ( WARN ) : Shutting down all open connections

war es dann fertig.

Z-Push musste danach nochmal neu installiert werden, da es während Zarafa Update deinstalliert wurde.

lg
Rob

michael.putzinger · September 1, 2015, 1:43am

Hallo,

ich habe aktuell exakt das selbe Problem, allerdings mit einem UCS 3.2.4 und einer größeren DB (~63GB), aber dafür 12GB RAM.
Allerdings ist die Auslastung des Systems absolut ruhig. Lediglich die HDD Auslastung ist auf meiner VMWare leicht angestiegen.

Mein Join Script hängt jetzt schon seit 5 Std. an der selben Stelle und ich weiss nicht ob sich da jetzt überhaupt noch was tut. Soll ich da noch warten oder gibts da wirklich ein Problem?
Vielleicht hat es bei jemandem auch so lange gedauert?
Kann ich das etwas beschleunigen mit einer SSD? Könnte den Datastore der VM auf einen SSD Datastore für die Migration verschieben.

LG, Michael

thorp-hansen · September 1, 2015, 6:07am

Hallo,
Im Zweifelsfall würde ich immer warten, anstatt das Script abzubrechen - damit könnte dann letztendlich doch mehr in die Binsen gehen.
Zarafa aktualisiert und indiziert an der Stelle - je nach DB Größe kann das dauern.

Ich denke eigentlich nicht, dass SSDs hier so signifikant einen Unterschied machen würden, lasse mich aber gern eines besseren belehren.

Gruß,
Jens Thorp-Hansen

michael.putzinger · September 1, 2015, 6:10am

Naja, ich hab auf jeden fall nach 6 Std. abgebrochen …
Ergebnis: MYSQL DB zerschossen
zum Glück nur im Testsystem
heute versuch ichs via SSD. Ich klone gerade mein Live System auf die Test SSD
und dann lass ich es einfach mal laufen…

LG, Michael Putzinger

fbartels · September 2, 2015, 6:04am

Eine SSD wird per se hier keinen großen Geschwindigkeitsgewinn bringen. Viel bedeutender ist hier ein entsprechendes Tuning der MySQL Einstellungen (innodb_buffer_pool_size, innodb_log_file_size, etc).

Weiteres zum Tuning der Datenbank findet sich im Handbuch, sowie der kürzlich im Zarafa Blog veröffentlichten Performance Blogserie (Part 1 & Part 2). Für Zarafa Ńutzer mit einer aktiven Subskription gibt es bei unserem Support auch einen “Tuning Guide” welcher die Informationen aus den bereits genannten Quellen und noch ein paar zusätzliche Tricks in destilierter Form enthält.

michael.putzinger · September 2, 2015, 6:38am

Hallo in die Runde,

kurzer Zwischenbericht nach meinem Update auf einer SSD.
Ursprünglich hatte ich ja mein Update auf einem “normalen” HDD Datastore im RAID5 Verbund auf einem IBM Hostserver in einer VMWare ESXi 5.5 Umgebung durcgeführt, und jetzt auf eine Single SSD (ohne RAID) geklont und dort das selbe Update nochmal durchgeführt. Auf der SSD dauerte es 4 Std bis alles fertig war.
Zuvor hatte ich ja nach 7 Std. abgebrochen ohne zu wissen wie lange es noch gedauert hätte. Somit hat das für mich schon einen bedeutenden Speed Zuwachs gegeben.

Aber bzgl. der Tuning Tipps werde ich mich auf jeden Fall mal mit unserem DB Spezialisten zusammensetzen.
Der genannte Tuning Guide klingt auch interessant, schliesslich haben wir ja eine gültige Subscription.
Muss ich mich gleich mal schlau machen!

Evtl. versuch ich es nochmal auf dem normalen Raid Verbund nach DB Tuning um den Geschwindigkeitsunterschied zu sehen wenn ich zuviel Zeit hab

Danke jedenfalls für die Tipps!
lg, Michael Putzinger

fbartels · September 2, 2015, 7:06am

Der ausschlaggebende Faktor war hier sicherlich das Raid 5. dba.stackexchange.com/questions … stallation

michael.putzinger · September 2, 2015, 9:25am

Hallo nochmal,

entweder ich bin zu blöd diesen Guide zu finden, oder muss ich den explizit anfordern?
LG, Michael Putzinger

fbartels · September 2, 2015, 9:33am

Der Guide muss bei unserem Support angefordert werden.