Eine ganz kurze Notiz für mich selbst – und für andere Betroffene: Wie stellt man ein bestehendes OTRS3-Ticketsystem von der Attachment-Speicherung in MySQL-BLOBs auf dateisystembasierende Speicherung derselben um?
Es ist, wie es ist: Wer ein Ticketsystem betreibt, bei dem er die User auffordert, ihnen Screenshots oder Logdateien als Attachment zu schicken, und wenn das Ticketsystem selbige Attachments dann als BLOBs in der MySQL-Datenbank ablegt, der wird alsbald eine riesengroße Datenbank bekommen – was die (mindestens) tägliche Sicherung immer unbequemer und unhandlicher werden lässt.
Wie schön wäre es doch, wenn man die Datenbank ihrem Namen entsprechend nur zum Speichern der Daten verwenden könnte, sowie die Speicherung der Dateien wiederum dem Namen entsprechend dem Dateisystem anvertrauen könnte. Derartige Datei-Halden kann man viel einfacher inkrementell oder differentiell sichern – und ggf. veraltete überflüssige Riesen-Attachments händisch herauslöschen.
Lange Bauchschmerzen und langes Googlen brachte mich hierher: Umstellung ArticleStorageDB auf ArticleStorageFS. Der User „Dennis“ berichtet hier im Jahr 2007 von der Umstellung einer OTRS-Datenbank von datenbankbasierende auf eine dateisystembasierender Attachment-Speicherung mit Hilfe eines Perl-Skriptes von Stefan Bedorf aus dem Jahre 2005. Wichtig: Das ist nicht mehr aktuell!
Was ich jetzt nachfolgend schreibe aber sehr wohl:
Erster Schritt: Backup machen.
’nuff said.
Zweiter Schritt: Voreinstellung ändern
Im Backend das „Ticket::StorageModule“ von „ArticleStorageDB“ auf „ArticleStorageFS“ umstellen. Einfach in der SysConfig nach „StorageModule“ suchen …
… und umstellen.
Wie User „Dennis“ richtig bemerkt, gilt dies natürlich nur für alle zukünftigen Tickets. Alle bestehenden Tickets, die mit ihren fetten Attachments die Datenbank zusauen, zeigen sich davon unbeeindruckt.
Dritter Schritt: Bestehende Tickets konvertieren
User „Dennis“ berichtet, dass er das nachträgliche Herausspeichern der Attachments früherer Tickets mit Hilfe eines Perl-Skriptes von Stefan Bedorf erledigt hat. Das funktionierte, soweit ich das verstehe, unter OTRS1 – aber heute unter OTRS3 nicht mehr. (Googlet man weiter, findet man irgendwo eine angepasste Version, die auch unter OTRS2 arbeitet – aber auch die tut es auf heutigen Systemen nicht mehr).
Aber: Unter obigem Weblink liefert im Oktober 2008 der Admin „monotek“ den rettenden Hinweis: Es gibt mittlerweile ein im Lieferumfang von OTRS befindliches Tool, das das Kunststück mit Bordmitteln vollbringt. Es findet sich unter $OTRSHOME/bin/otrs.ArticleStorageSwitch.pl – in meinem Fall unter /opt/otrs/bin/otrs.ArticleStorageSwitch.pl.
Wie wirft man es also an? Im Grunde genommen ganz einfach:
/opt/otrs/bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS
Merke: „S“ wie „Source“ – „-s ArticleStorageDB“, und „D“ wie „Destination“ – „-d ArticleStorageFS“. Der Vorgang zieht sich dann etwas:
[root@centos ~]# /opt/otrs/bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS
NOTICE: 1/9295
NOTICE: 2/9295
NOTICE: 3/9295
NOTICE: 4/9295
NOTICE: 5/9295
:
:
:
NOTICE: 9295/9295
NOTICE: done.
[root@centos ~]#
Ich habe das Skript im Kontext des Root-Users ausgeführt, der die Verzeichnisse und Dateien aber anschließend dem User „root:apache“ mit „drwxrwsr-x“-Rechten aushändigte. Das genügt, damit die OTRS-Benutzer weiterhin an ihrer Attachments heran kommen, und dass Apache bei neuen Tickets neue Ordner und Dateien anlagen kann.
Selbige lagern anschließend unter $OTRSHOME/var/article/:
[root@centos ~]# ls -la /opt/otrs/var/article/
insgesamt 28
drwxrwsr-x 5 otrs apache 4096 2. Mär 13:51 .
drwxrwxr-x 14 otrs apache 4096 30. Nov 14:19 ..
drwxrwsr-x 5 root apache 4096 2. Mär 13:46 2010
drwxrwsr-x 14 root apache 4096 2. Mär 13:48 2011
drwxrwsr-x 5 root apache 4096 2. Mär 13:49 2012
[root@centos ~]#
Fertig – abputzen! Die MySQL-Datenbank ist wieder rank und schlank – richtig ist, dass man die beiden Tabellen article_attachment und article_plain noch optimieren sollte, um deren Tabellen-Overhead nun abzuräumen. Wie das geht, hat im Original-Link User „dennis“ gut beschrieben.
Keine Kommentare möglich.