Checkliste
Diese Liste gilt für eine Indexverkleinerung im Prod-System. Evtl. vorher im Testsystem durchspielen.
Komplette Doku des IndexRepairKit beachten!!!
Vorbereitungen
- Ausreichend temporären Plattenspeicher bereitstellen, auf den der CCM-Indexjob zugreifen kann (3 x Indexgröße); am besten auf derselben Platte, wenn nicht möglich, muss auf einer Kopie des Index gearbeitet werden.
- Aktuelles IndexRepairKit auf Server bringen und einrichten: IndexRepairKit
- Lucence Query erstellen (Lucene-Suche, welche Daten entfernt werden sollen, s.u.)
- Termin für produktive Indexverkleinerung vereinbaren (Downtime CCM-Index) (geschätzte Gesamtdauer: abhängig von Indexgröße und Hardwareperformance, z.B. 130 GB war ca. 8h)
Indexverkleinerung
- CCM-IndexJob stoppen; Achtung!!! Während der gesamten Kopier-, Lösch- und Optimierungsvorgänge muss der CCM-Index-Job ausgeschaltet bleiben, da es sonst zu Datenverlust kommt!
- Backup des Index anlegen: Index (z.B. tomcat_all/index/ccm_index_pre) als ccm_index_backup auf eine andere Platte kopieren, Größenvergleich der Indexdateien, Funktionstest des Backups
- Wenn die Optimierung auf einer separaten Platte stattfindet (der zur Optimierung benötigte Platz steht nicht auf der Platte des Originalindex zur Verfügung)
- Index noch mal als ccm_index_copy auf die Optimierungsplatte kopieren (Verkleinerung wird dann dort durchgeführt); Größenvergleich der Indexdateien
- Indexverkleinerung und -optimierung: reIndex.sh auf ccm_index_copy ausführen (Löschen und optimieren -> für 150 GB ca. 4-5h, evtl. vorher testen)
- Qualitätssicherung (Verzeichnis ccm_index_copy testweise an B3P_FLEXIBLE_INDEX_CORR_DIRECTORY_BACKUP anbinden, im IndexManagement Übersicht anzeigen lassen, Anzahl Dokumente vergleichen mit Backup / Original)
- Originalindex ccm_index_pre löschen; optimierten Index ccm_index_copy kopieren als neuen Originalindex ccm_index_pre
- Wenn die Optimierung auf dem Originalindex durchgeführt wird (der zur Optimierung benötigte Platz steht auf der Platte des Originalindex zur Verfügung)
- Indexverkleinerung und -optimierung: reIndex.sh auf Originalindex ccm_index_pre ausführen (Löschen und optimieren -> für 150 GB ca. 4-5h, evtl. vorher testen)
- Qualitätssicherung (im Indexmanagement Übersicht anzeigen lassen, Anzahl Dokumente vergleichen mit Backup)
- Wenn optimierter Index trotz Test korrupt sein sollte: Originalindex mit Backup wiederherstellen
- Zugriff testen
- CCM-IndexJob starten (kann wegen Index-Warmup einige Minuten dauern)
- Beauftragen: Temporären Speicher wieder freigeben und wegräumen lassen
Beispiel für Eingaben im IndexRepairKit (Löschen mit Optimierung)
Auf jeden Fall vorher überprüfen/testen!!! (IndexManagement>Suche)
2 [Löschen]
B3P_FLEXIBLE_INDEX_CORR_DIRECTORY
/opt/B2BP/adm…./index/ccm_index_copy [Pfad, wenn nicht der Originalindex bearbeitet wird, sonst “N”]
2 [Flexible Index]
2 [KeywordAnalyzer]
B3P.Date:2015* OR Header.B3P.Date:2015* … [Lucene-Query, muss angepasst werden!!!]
J [optimieren]
N [unbegrenzt viele boolean Ausdrücke]
J [Bestätigung DB-Zugangsdaten]
J [sicher, dass gelöscht werden soll?]
Entwickeln der Lucene-Query
Die Lucene-Query, die im IndexRepairKit angegeben werden muss, kann in der B2B im IndexManagement>Suche entwickelt und getestet werden. Die Dokumente, die eine Suche dort findet, werden durch das IndexRepairKit gelöscht.
Beispiele:
Löschen aller Dokumente des Jahres 2014 B3P.Date:2014* OR Header.B3P.Date:2014*
Löschen aller Dokumente der Jahre 2014 und 2015 B3P.Date:2014* OR Header.B3P.Date:2014* OR B3P.Date:2015* OR Header.B3P.Date:2015*
Funktionstest des Backups
Das Index-Backup kann als separater Index in der Extension B3P_INDEX_MANAGEMENT registriert werden. Dazu muss ein neuer Name an die Eigenschaft indexes=…
mit Semikolon angehängt werden. Dieser Name muss zusätzlich als GlobalProperty angelegt werden, die als Wert den Pfad des Index-Backups hat.
Beispiel:
B3P_FLEXIBLE_INDEX_CORR_DIRECTORY_BACKUP=/opt/B2B/tomcat_all/index/ccm_index_pre_backup
Das Index-Backup kann jetzt im IndexManagement geprüft werden (Übersicht anzeigen lassen, Suchen durchführen).
Fehleranalyse
Falls ein OutOfMemoryError auftritt, kann es helfen, in der reIndex.sh / reIndex.bat die Filesystem-Klasse auszutauschen:
org.apache.lucene.store.MMapDirectory
ersetzen durch
org.apache.lucene.store.NIOFSDirectory
MMap = MemoryMap, legt einen großen Teil des Index im Hauptspeicher ab, kann bei großen Indizes ein Problem geben. Evtl. schneller als NIOFS, bei kleinen Indizes daher zu bevorzugen.
View Me Edit Me