agorum core storage auslagern (MariaDB und MySQL)

Zunächst legen Sie fest, was genau in den agorum core storage ausgelagert werden soll, um die Datenbank zu verkleinern. In der Regel befindet sich der auszulagernde Content in folgenden Bereichen:

/agorum/roi/Files (Dateien)
/Home (Eigene Dateien aller Benutzer + Mails)
/agorum/roi/Workflow

Wird ein Dokument ausgelagert, dann werden auch zugehörige Previews, Historie, Textextrakte und Metadaten-XMLs mit auf das agorum core storage ausgelagert.

Dies bedeutet, dass während der Auslagerung mit einem erhöhten Speicherplatz gerechnet werden muss. Wir gehen im Standard von ungefähr der doppelten Größe aus. Dies kann jedoch, je nachdem welche Daten Sie in der Datenbank haben, variieren, also höher oder niedriger ausfallen. Achten Sie daher vor der Auslagerung darauf, dass Ihre darunterliegendes Festplattensystem genügend freien Speicher zur Verfügung stellt (kalkulieren Sie einen Puffer ein). Beobachten Sie auch während der Auslagerung die Speichernutzung. Wenn das Festplattensystem voll ist, führt dies zu Betriebsproblemen von agorum core.

Um zu prüfen, welcher Content nun noch in der Datenbank liegt, können die nachfolgend beschriebenen Aufrufe verwendet werden.

Speicherverbrauch der einzelnen Content-Tabellen

---

Die Informationen sind in dieser Dokumentation auf das Wesentliche gekürzt. Um herauszufinden, wo besonders viel Content liegt, helfen Ihnen die folgenden Selects:

Row
Anzahl der Einträge in der Tabelle

Data_length
Größe der Tabelle in Bytes

Index_length
Größe des Tabellenindex in Bytes

Den Content berechnen Sie aus der Summe von Data_length + Index_length.

Beispiel

show table status like '%contentstore%';

+---------------------------+-------+-------------+--------------+
| Name                      | Rows  | Data_length | Index_length |
+---------------------------+-------+-------------+--------------+
| indexedcontentstore       | 21549 |    62373888 |       540672 |
| nonindexedcontentstore    |    16 |     4423680 |        16384 |
| unknownformatcontentstore | 28427 |   129204224 |      1589248 |
+---------------------------+-------+-------------+--------------+

Hier ergibt sich als Summe der Content-Elemente ca. 189 MB:

(Summe ( Data_length + Index_length) / 1024 / 1024)

196.001.792 + 2.146.304 = xxxxx142.011.596 /1024 = 138.683,199 /1024 = ca. 135,43

Ist das Verhältnis des hier verzeichneten Contents zum agorum core storage deutlich größer, prüfen Sie Folgendes:

• Serverpapierkorb
• Stichproben
• Index

Serverpapierkorb prüfen

---

Dokumente im Serverpapierkorb werden nicht ausgelagert. Gelöschte Dokumente befinden sich nur im agorum core storage, wenn Sie diese vor der Löschung auch ausgelagert haben. Nehmen Sie dementsprechend erstmalig eine Auslagerung in den agorum core storage vor und es befindet sich viel im Serverpapierkorb, verbleibt dieser in der Datenbank und beansprucht Speicherplatz.

Über folgende Selects finden Sie heraus, wie hier das Verhältnis ist.

Select 1

# size trash on storage
select sum(b.contentsize)/1024/1024 from globalobject a, fileobject b, backendinformation c where c.id = 0 and a.expirationdate != 0 and a.id = b.id and a.id = c.docid;

Sample result: 19673 MB

Liefert die Contentmenge in Megabytes für alle im Serverpapierkorb befindlichen Objekte, deren Content auf dem agorum core storage liegt.

Select 2

# size in trash in all
select count(*), sum(b.contentsize)/1024/1024 from  globalobject a, fileobject b where a.id=b.id and a.expirationdate != 0;

Sample result: 39262 MB

Liefert die Gesamtmenge im Serverpapierkorb. Die in der Datenbank befindliche Menge ist dann die Differenz aus beiden.

In diesem Beispiel befinden sich noch 19589 MB in der Datenbank:

39262 MB - 19673 MB = 19589 MB

Durch das Löschdatum im Serverpapierkorb wird sich dieser Content von selbst bereinigen.

Stichproben prüfen

---

Um stichprobenartig zu prüfen, was noch in den Content-Tabellen vorhanden ist, verwenden Sie nachfolgenden Select.

Select

select docid from indexedcontentstore where id = 0 order by docid desc limit 10;

Fragt ab, was die letzten 10 IDs sind, die in der Tabelle indexedcontentstore lagern. Sie erhalten eine Liste zurück, etwa folgende:

+-----------+
| docid     |
+-----------+
| 280755443 |
| 280755431 |
| 280755419 |
| 280755407 |
| 280755395 |
| 280755383 |
| 280755371 |
| 280755349 |
| 280755337 |
| 280755317 |
+-----------+

Diese Liste fügen Sie jetzt in einen JavaScript-Codeschnipsel ein und führen ihn in der JavaScript-Konsole aus, um herauszufinden, wo die IDs liegen:

let objects = require('common/objects');
    
[
  280755443,
  280755431,
  280755419,
  280755407,
  280755395,
  280755383,
  280755371,
  280755349,
  280755337,
  280755317
]
.map(id => id + ': ' + objects.find(id).anyFolderPath)
.join('\n');

In diesem Beispiel sind veraltete Workflows betroffen:

280755443: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755443.txt
280755431: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755431.txt
280755419: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755419.txt
280755407: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755407.txt
280755395: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755395.txt
280755383: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755383.txt
280755371: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755371.txt
280755349: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755349.txt
280755337: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755337.txt
280755317: /agorum/roi/Workflow/2017/01/28/InboxWatcher280755317.txt

Lucene-Index prüfen

---

Ist noch der Lucene-Index im Einsatz (bei Solr liegt der Index nicht mehr in der Datenbank), sind gewisse Teile noch in der Datenbank enthalten. Dies prüfen Sie über folgenden Select.

Select

select sum(length)/1024/1024 from index_document_t;

Mit diesem Select erhalten Sie den Verbrauch des Suchindexes in Megabyte. Ist das Ergebnis null, ist der Index nicht in der Datenbank vorhanden. Sie verwenden in diesem Fall höchstwahrscheinlich bereits Solr.