ImpEx Frage zum Massenimport

[Rob_K]

Hallo,

ich möchte 1.050.000+ posts von IPB 1.2 zum aktuellen VB konvertieren.
sieht auch soweit ganz gut aus...

Ich frage mich allerdings, wieviele Posts ich auf einmal konvertieren kann?
Ich wollte nicht unbedingt eine Woche mit dem konvertieren verbringen, zumal mein Forum in dieser Zeit ja nutzlos ist. :)

Ich habe 2 dedizierte Server laufen, wobei einer Webserver (Sempron 2300+, 256 MB RAM) und einer MySql-Server (Sempron 2300+, 1 GB RAM) ist.

Hat jemand Erfahrungen mit solch großen Importen oder eine alternative Idee?
Ein Script direkt auf der Shell wäre bestimmt um einiges schneller als ImpEx.

Speichert ImpEx die Daten in PHP-Variablen zwischen oder werden direkt MySql-Befehle mit Subselects usw für das konvertieren verwendet?

Danke,
Robert

[StGaensler]

Dazu habe ich keine Erfahrungswerte. Es liegt daran, wie lange ein php-Script bei dir laufen darf. Je niedriger du die Anzahl nimmst, desto wahrscheinlicher ist es, dass das Script nicht hängen bleibt, und durchläuft, und je höher du die Anzahl nimmst, desto wahrscheinlicher ist es, dass das Script zu lange braucht, und dann vom Server "abgewürgt" wird.

Probier es einfach mal mit dem Standardwert, der schon drinnen steht. Wenn es nicht funktioniert, wirst du den Wert erniedrigen müssen.

All zu lange sollte das auch nicht dauern. Die Seite, die die Beiträge übernimmt, wird ja automatisch, wenn die Anzahl der Beiträge, die du eingestellt hast, konvertiert sind, wieder neu geladen, und macht dann weiter. Du kannst das dann einfach laufen lassen, bis es fertig ist (oder bis ein Fehler auftaucht - was ich nicht hoffe).

[simplex]

Speichert ImpEx die Daten in PHP-Variablen zwischen oder werden direkt MySql-Befehle mit Subselects usw für das konvertieren verwendet?
Ich habe mir den Code nicht genau angesehen, aber da Impex ja auch die Verschmelzung von bestehenden Boards zulässt, die auf unterschiedlichen Servern liegen, gehe ich davon aus, dass die Daten in php zwischengespeichert werden. Außerdem sind aus Kompatibilität zu älteren MySQL-Versionen Subselects nicht zu erwarten. Dafür spricht auch, dass bei meinem Import sowohl das memory_limit der php.ini als auch das max_allowed_packet in der my.cnf überschritten wurden. Beide Werte würde ich also für das Update dringend hochsetzen. Genauso sollten natürlich das Zeitlimit von php und die Puffergrößen (v.a. Schreib- und Sortier-Puffer) von MySQL (obwohl die angesichts des 1 GB RAM wohl sowieso schon weit oben sind) angepasst werden. Ach ja, und den Query Cache würde ich, da ja keine wiederholten DB-Operationen auftreten sollten, für die Dauer des Vorganges abschalten.
Ich frage mich allerdings, wieviele Posts ich auf einmal konvertieren kann?
Ich wollte nicht unbedingt eine Woche mit dem konvertieren verbringen, zumal mein Forum in dieser Zeit ja nutzlos ist. :)Ich mache mal die vorsichtige Schätzung, dass da eine lange Nacht reichen sollte. Ich habe jedenfalls einmal zwei 400.000 Posts-Borads gemerged (die allerdings schon beide vb3 waren) und es hielt sich in Grenzen.

[Rob_K]

Danke für die Hinweise. Die Speichervariablen werde ich erhöhen und den Querycache deaktivieren. Schauen wir mal, obs klappt.

Rob

[Rob_K]

Nachtrag:

Wie sieht das eigentlich aus, wird der Suchindex irgendwie nachgeneriert?
Oder sollte ich gleich die MySql-Volltextsuche aus dem Debugmodus verwenden?

Rob

[Hoffi]

Im ACP unter Importieren & Wartun dann Zähler aktualisieren. Dort kann der Index neu aufgebaut werden.

[Rob_K]

Alles klar. Ich denke mal das dauert dann eine Weile :)

Noch eine wichtige Frage:
Kann ich beim importieren der Posts sozusagen eine Pause machen und dann später weiter? Wenn es sehr lange dauert und die Verbindung wird getrennt wäre das sicher nich so toll, müsste ich dann neu anfangen :/

[Hoffi]

Also ich hatte es mal das bei einem Test-Import die Verbindung gekappt wurde. Dann kan eine Nicht gefunden Meldung in Fenster, ist klar. Als die Verbindung wieder da war, hab ich rechtsklick - neu laden gemacht und es ging problemlos weiter.

Ob das immer klappr kann ich natürlich nicht sagen!

[simplex]

Nachtrag:

Wie sieht das eigentlich aus, wird der Suchindex irgendwie nachgeneriert?
Oder sollte ich gleich die MySql-Volltextsuche aus dem Debugmodus verwenden?

RobMan kann den Suchindex zwar wie oben beschrieben neu erstellen lassen, aber ich finde es praktischer, die MySQL-Volltextsuche zu benutzen. Bei den Suchergebnissen merkt man zwar kaum einen Unterschied, aber die Erstellung des Volltext-Index nimmt meiner Erfahrung bei der Neuerstellung erheblich weniger Zeit in Anspruch und wenn seine Backups immer gleich von der kompletten Datenbank zieht (ohne die Tabellen des vb-Suchindex auszuschließen), wird jedes einzelne Backup erheblich(!) kleiner. Für die Volltextsuche stehen da ja nur bei den CREATE-Befehlen für die Tabellen post und thread ein paar Wörter mehr zum Anlegen des Volltext-Index, während bei der vb-Variante ein paar Milliönchen Datensätze für die Suchbegriffe mehr stehen.

[Rob_K]

Ja das ist klar. Die Frage ist eben nur, wie sich das weiterem Wachstum des Forums verhält. Welcher Index ist am Ende besser/schneller, wenn es um mehrere Mio. Datensätze geht?

Mich würde interessieren, wie Riesenforen das machen ...

[Rob_K]

Ich konnte alles erfolgreich importieren. ImpEx ist wirklich gut.
Für die 1.000.000+ posts hat er keine 3 stunden gebraucht ...

für die suche verwende ich die MySql-FULLTEXT-Suche - der Index ließ sich deutlich schneller erstellen (unter 60 min), als der des VB.