Hi Jan,
On 7/9/12 14:42 , [email protected] wrote:
die MySQL-DB einer von uns betreuten (2.4.9)-OTRS Instanz ist relativ
groß: article_plain umfasst 90GB, article_attachment 67GB. Die
MySQL-Datenbank reagiert dadurch (?) inzwischen recht träge; davon
abgesehen bekomme ich auch mehr und mehr Angst vor einem Crash und
anschließendem myisamchk. Einfache Änderungen (z.B. Aktivierung der
statischen Suche) haben wir bereits seit längerem durchgeführt.
Hat jemand ähnliche Bedingungen bei OTRS-Instanzen beobachtet? Wie
geht Ihr mit solchen Datenmengen um? Gibt es offizielle Empfehlungen
seitens OTRS.com?
Wir überlegen, ob uns ein Wechsel zu postgrsql etwas bringen könnte?
Fährt jemand aus der Community derartig große OTRS-Datenbanken?
Wir haben oft solche Fälle (größer 300GB).
Du kannst die Anhänge ins File-System schieben, dies entlastet die
Datenbank sehr!
a) Für neue Anhänge
-> SysConfig -> Ticket -> Core::Ticket -> Ticket::StorageModule -> FS
b) Für alle bisherigen Anhänge (nachträglich)
-> bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d
ArticleStorageFS
Hinweis: Du musst beim Backup zukünfig sicherstellen, dass auch das FS
mit der Datenbank gesichert wird!
Ein einfacher wechsel zu postgrsql bringt keine großartigen Veränderungen.
PS: Wir hatten bisher diesbezüglich keinen crash. Du kannst mich aber
bei Probemen gerne anschreiben wenn Du Hilfe brauchst.
--
Mike Eduard
Enterprise Services for OTRS
Znuny GmbH // Marienstraße 11 // 10117 Berlin // Germany
P: +49 (0) 30 60 98 54 18-0
F: +49 (0) 30 60 98 54 18-8
W: http://znuny.com
Location: Berlin - HRB 139852 B Amtsgericht Berlin-Charlottenburg
Managing Director: Martin Edenhofer
---------------------------------------------------------------------
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de
