Alles gut ! :)
Ich habe den Agenten gefunden (http://lists.otrs.org/pipermail/otrs-de/2006-February/005646.html) und auch auf unserem Testsystem getestet.
Er funktioniert mit aktuellen OTRS versionne leider nicht, da die Funktionen GetTicket, GetArticle in ArticleGet und TicketGet umbenannt wurden.
Anbei eine modifizierte Version, die nun unter 2.0.X funktioniert. Wiederum ohne Garantie auf Funktion!!
Nach dem Bewegen der Tickets und Umstellen des Backend auf StorageFS funktioniert alles gut. Der Vorteil der Auslagerung im Filesystem ist neben dem Geschwindigkeitsvorteil (mySQL DB is nun 1/20el der ursprünglichen Größe) auch, dass selektiv alle Attachments und Plain Mails die älter als ein gewisses Alter sind archiviert werden können und nicht jedes Mal gesichert werden müssen - ein einfaches "find ... -print0 | xargs -0 rm" tut hier Wunder.
Im OTRS äußert sich das Ganze dann so wenn die plain Mails und Attachments to einem Ticket im FS gelöscht wurden:
1) Klickt mann auf "plain" oder "klar", kommt eine Fehlermeldung
2) Attachemnts die nicht im Filesystem vorhanden sind werden im Frontend nicht mehr angezeigt (das Datei Symbol in der Meldung ist weg)
An die OTRS Entwickler: Währe es nicht gut, wenn der "plain" / "klar" Link bur angezeigt wird wenn die Datei auch im Filesystem vorhanden sind (analog den Attachments) ?
Danke noch ein Mal an Stefan Bedorf für den super hilfreichen MoveArticleParts.pm generic agent. Ist sicherlich ein Agent, der auch in die offizielle OTRS Version einfließen sollte.
Grüße,
Robert Heinzmann
-------- Original-Nachricht --------
Datum: Fri, 28 Jul 2006 16:35:49 +0200
Von: "Robert Heinzmann"
Stimmt,
da gab es mal einen Agenten. Ist auch ein Ansatz dem ich noch ein Mal nachgehen werde.
Bezüglich der Datenbanklösung habe ich noch ein mal geforscht. Danach befinden sich in article_plain die e-Mails zusammen mit den attachments - also die kompletten e-Mail Daten (wie der name schon sagt - dumm von mir :).
Diese benötige ich denke ich nur wenn ich im Frontend auf "klar" oder im Englischen Frontent "plain" klicke. Dies tun wir sehr selten bis nie und somit wäre eine Wartezeit von einigen Sekunden (ca 30 derzeit ohne index) auch machbar.
Article_plain ist damit ein kandidat für die Storage Engine ARCHIV.
Testen muss ich das Ganze allerdings noch.
Die Tabelle article_attachment lässt sich sicherlich auch nicht so gut komprimieren, da die meisten Attachments bei schon gepackt sind. Aber auch diese Tabelle währe ein Kandidat, da auch hier der Zugriff nicht super schnell erfolgen muss. Also kann auch hier auf indexe verzichtet werden.
Robert Heinzmann
-- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl