Konsistenzprüfung

Allgemeines

Diese Abschnitt beschreibt Kommandos für die MyCoRe Kommandozeile, um die Konsistenz der eigenen Anwendung zu prüfen und ggf. Korrekturen vorzunehmen. Dabei wird vor allem von den flach auf der Platte gespeicherten Metadaten und Bildern ausgegangen. Diese stellen die Grundlage für eventuelle Korrekturen dar, da in MyCoRe einige Datenteile nur sekundär wirken bzw. für eine akzeptable Performacne-Verbesserung existieren. Ein Überblick dazu ist auf der Seite Backup und Recovery zu finden.

MyCoRe-Objects und -Derivates

MyCoRe-Objekte können innerhalb der Metadatenstrukturen Verweise auf externe URLs aber auch auf andere MyCoRe-Objekte innerhalb der Anwendung enthalten. Ein Spezialfall sind dabei Verweise auf Kindobjekte innerhalb der Metadatenstruktur <structure /> .

Test der Derivate-Einträge in den Objekten

In <structure /> sind auch Verweise auf die angefügten Derivate abgelegt. Mit dem nachfolgenden Kommando aus der Kommandogruppe MCRObjectCommands kann geprüft werden, ob alle eingetragenen Derivate auch als XML-Metadaten vorhanden sind. Dies sagt noch nichts über die innere Konsistenz des Derivates aus!!!

mycore.sh check derivate entries in objects for base {mcr_base_id des Objektes}

Reparaturhinweis: Es ist abzuklären wohin und warum die Derivate verschwunden sind. Ist klar, dass das Derivate nicht mehr existiert, so sollte der Eintrag in den Objektdaten entfernt werden. Am sinnvollsten ist der direkte Zugriff auf das MCRObject unter data/metadata mittels geeignetem XML-Editor z. B. vi .

Test der Objekt-Einträge in den Derivaten

Nun kann auch der umgekehrte Weg geprüft werden.

mycore.sh check object entries in derivates for base {mcr_base_id des Objektes}

Reparaturhinweis: Offensichtlich sind die fehlerhaften Derivate nicht mehr verknüpft. Es ist abzuklären, ob nur der Verweis im Objekt fehlt oder das Derivat nicht mehr zugeordnet werden kann. In diesem Fall kann das Derivate gelöscht werden. Hierfür sollte zuerst das Kommando

mycore.sh delete derivate {derivate_id}

versucht werden. Hilft dies nicht, müssen die Restfragmente aus dem Metadaten-Store auf der Platte sowie auf dem File-Store händisch entfernt werden. Weiterhin sollten die Einträge in der SQL-Tabelle MCRFSNODES entfernt werden:

echo "use {xyz}; delete from MCRFSNODES where OWNER = '{derivate_id}'" | mysql

MyCoRe-Derivate Store-unabhängig

Nachdem die XML-Seite der Anwendungsdaten getestet wurde, soll nun der Inhalt der Derivate näher untersucht werden. Hierbei ist zu unterscheiden zwischen Tests, welche unabhängig vom verwendeten Store-Modell sind und speziellen Test für einzelne Stores. Die MCRFSNODES-Tabelle kann aus Sicht der Derivate mit folgendem Kommando auf Konsistenz geprüft werden:

mycore.sh check derivates of mcrfsnodes with project id {project_id}

Hier wird geprüft, ob für ein Verzeichnetes Derivate Einträge in der MCRFSNODES hat und ob diese korrekte Verweise auf existierende Dateien haben.

Im Gegenzug kann auch geprüft werden, ob in der Tabelle MCRFSNODES Einträge sind, welche keine existierenden Derivate mehr haben. Hierfür dient das Kommando:

mycore.sh check mcrfsnodes of derivates with project id {project_id}

Reparaturhinweis: Die Reparatur ist abhängig vom verwendete Store. Für den Store IFS2 sind in den folgenden Abschitten Wege aufgezeigt.

MyCoRe-Derivate des IFS2-Store

Der IFS2 Store zeichnet sich dadurch aus, dass alle zum Wiederherstellen benötigten Daten direkt auf der Platte stehen. Somit kann aus einer einfachen File-Sicherung das Speichersystem wieder hergestellt werden. Derzeit enthält jedes Derivate-Verzeichnis im IFS2-Store zusätzlich eine Datei mcrdata.xml. Diese beinhaltet eine Beschreibung der abgelegten Daten. Sie wird aber im aktuellen Codestand noch nicht genutzt, jedoch existieren bereits Kommandos, welche diese Datei mit dem aktuellen Stand in Verzeichnis zu synchronisieren.

Reparaturhinweis: Die Synchronisation der Daten kann mittels folgender Kommandos wieder hergestellt werden.

mycore.sh repair mcrdata.xml for project id {project_id} in content store {store_id}

mycore.sh repair mcrdata.xml for object {object_id} in content store {store_id}

mycore.sh repair mcrdata.xml for derivate {derivate_id} in content store {store_id}

Um die Konsistenz zwischen den Derivate-Verzeichnissen auf der Platte und der Tabelle MCRFSNODES zu prüfen sind die nachfolgenden Kommandos entwickelt worden. Hierbei ist zu beachten, dass eine Reparatur für ein ganzes Projekt nur bedingt sinnvoll ist. Vorher sollten auf jeden Fall mit den Check-Kommandos die fehlerhaften Tabelleneinträge ausgelistet und verifiziert sein!

mycore.sh check mcrfsnodes for project id {project_id} of content store {store_id}

mycore.sh check mcrfsnodes for object {object_id} of content store {store_id}

mycore.sh check mcrfsnodes for derivate {derivate_id} of content store {store_id}

Reparaturhinweis: Die Repair-Kommandos leisten folgende Dinge:

  • Prüfen, ob es einen Eintrag für Dateien und Verzeichnisse der im Derivate vorhandenen Daten in der MCRFSNODES gibt. Repair legt fehlende Einträge neu an.
  • Prüfen, ob die Dateigröße und die MD5 Summe in der MCRFSNODES korrekt sind und bei repair diese aktualisieren.

mycore.sh repair mcrfsnodes for project id {project_id} of content store {store_id}

mycore.sh repair mcrfsnodes for object {object_id} of content store {store_id}

mycore.sh repair mcrfsnodes for derivate {derivate_id} of content store {store_id}

Bilddaten

Unter den Derivaten nehmen die Bilddaten eine besondere Rolle ein. Über den in MyCoRe integrierten IView2-Bildbetrachter werden die Bilder in gekachelter Form dargestellt. Dieser wie auch das DFGViwerServlet nutzen außerdem mets.xml-Dateien.

IView2-Daten

Der IView2 arbeite mit dem Tiler-Konzept. Hier werden die Bilder in Kacheln verschiedener Zoom-Stufen zerlegt und in einem speziellen Store abgelegt. Maßgeblich ist die SQL-Tabelle MCRTileJob hier ausschlaggebend. Grundsätzlich könne sowohl die Tabelle wie auch das Verzeichnis mit den Kacheln gelöscht und neu angelegt werden. Es sei jedoch darauf hingewiesen, dass dies je nach Bildumfang SEHR lange dauern kann, bis alle Bilder wieder neu gekachelt sind!!!

Das Kommando prüft alle Kacheln und veranlasst das Bauen fehlender.

mycore.sh check tiles of all derivates

Detaillierter kann Derivat-bezogen vorgegangen werden.

mycore.sh check tiles of derivate {derivate_id}

Gelöscht werden kann das gesamte Kachelsystem mit

mycore.sh delete all tiles

wobei auch ein dediziertes Arbeiten mit

mycore.sh delete tiles of object {object_id}

oder

mycore.sh delete tiles of derivate {derivate_id}

möglich ist. Das Wiederherstellen erfolgt dann mit

mycore.sh tile images of all derivates

sowie wieder in kleinen Teilen mit

mycore.sh tile images of object {object_id}

oder

mycore.sh tile images of derivate {derivate_id}

METS-Daten

Für bereits bestehende mets.xml-Dateien kann auch eine Validierung erfolgen. Dabei ist aber ein vorheriges select -Kommando vorher erforderlich.

mycore.sh validate selected mets

Sind noch keine mets.xml-Dateien vorhanden und sollen diese schon mal in ihrer Grundform angelegt werden, so generiert das nacholgende Kommando diese für ein einzelnes Derivat {0} oder eine Derivatgruppe einer angegebenen Projekt-ID {0}

mycore.sh add mets files for derivate {0}

mycore.sh add mets files for project id {0}

Klassifikationen

Bei der Frage des Umgangs und der Wiederherstellung von Klassifikationen müssen drei Ansätze zu deren Handhabung unterschieden werden:

  1. Ausschließliche Bearbeitung über Eclipse oder ähnliche Werkzeuge im Quellcode der Anwendung
  2. Nutzung des Klassifikationseditors
  3. Rollen des Nutzer- und Rechtesystems von MyCoRe

Beginnen wir mit dem letzten Punkt. Mit Umstieg auf das User2-Modul werden alle Rollen (früher Gruppen) und ihre Struktur in der Klassifikation mcr-roles abgespeichert. Die Bearbeitung erfolgt direkt über den Klassifikationseditor. Daher ist es wichtig, nach jeder Änderung diese Klassifikation zu sichern, um sie ggf. wieder neu laden zu können. Ähnlich verhält es sich mit den Klassifikationen, welche über den Editor online änderbar sind. Je nach Häufigkeit der Änderungen müssen hier Exporte der Klassifikation(en) ggf. zyklisch durchgeführt werden. Vorher ist es angeraten, die Klassifikationen noch auf Datenfehler zu prüfen.

mycore.sh check all classifications

mycore.sh export all classifications to directory {dir} with save

Die so erzeugten Dateien können nun mittels Load/Update-Kommando wiederhergestellt werden. Ggf. sind vorher die SQL-Tabellen MCRCategory, MCRCategoryLabel und MCRCategoryLink zu löschen und mit

mycore.sh init hibernate

neu anzulegen. Das Einspielen erfolgt dann mit

mycore.sh update all classifications from directory {dir}

Um Inkonsistenzen in den Daten zu vermeiden, sollte immer die letzte Sicherung nach Änderungen am Klassifikationssystem verwendet werden! Im Falle einzelner beschädigter Klassifikationen können diese mit dem Commandline-Tool (CLI) mycore.sh auch einzeln eingespielt werden.

Wenn es "Lücken" gibt bei der positionInParent Angabe, dann werden diese mit folgendem Kommando entfernt. Das kann durch alte inzwischen behobene Fehler entstehen.

mycore.sh repair position in parent

Durch (alte) Fehler können die Links- und Rechte-Werte falsch sein. Diese sind aber erforderlich, um schnell zu überprüfen, ob ein Objekt in einer bestimmten Kategorie enthalten ist. Fehler werden behoben mit

mycore.sh repair left right values for classification {classification}

Kategorien, die kein Label haben, verursachen Probleme (bei Anzeige etc.). Das Kommando findet alle Label-losen Kategorien und hängt ein Label mit @text=@id in der Standard-Sprache an.

mycore.sh repair category with empty labels

mycore.sh check all classifications

überprüft die letzten beiden Probleme.

Nutzerdaten und Zugriffsrechte

Die Daten der einzelnen Anwendungsnutzer können mit den nachfolgenden Kommandos gesichert und bei Bedarf wieder geladen werden. Die erforderlichen Rollen sind bereits über die Klassifikationen vorher zu laden. Es gibt auch Kommandos für die Arbeit mit einzelnen Nutzern.

mycore.sh export all users to directory {dir}

mycore.sh import all users from directory {dir}

Die Zugriffsrechte sind differenziert zu betrachten. Es können folgende Gruppen ausgemacht werden:

  1. Zugriffsrecht eines einzelnen Objektes oder Derivates
  2. Zugriffsrechte für eine MCR-Base-ID für Objekte und Derivate
  3. Zugriffsrechte für einen MCR-Type für Objekte und Derivate
  4. Standardzugriffsrechte für Objekte und Derivate
  5. globale Privilegien

In den meisten Anwendungen werden die Typen 2-5 bei der Initialisierung einmalig geladen oder einmalig händisch nachgetragen. Somit bilden diese Informationen einen Teil der Anwendungsquelle und können z. B. im build-Prozess mit ant create.default-rules in die Tabellen MCRACCESS und MCRACCESSRULES jederzeit geladen werden. Dieses Vorgehen erfordert die Zugriffsstrategien MCRObjectTypeStrategy oder MCRObjectBaseStrategy.

Kritisch ist der 1. Typ. Dieser wird bei der Standardzugriffsstrategie verwendet und erfordert das Auslesen der gesamten Metadaten für Objekte und Derivate mit den save-Kommandos. Ein Recovery kann nur über ein erneutes Laden der Daten erfolgen (kein update!). Hier bleibt nichts weiter, als die entsprechenden SQL-Tabellen separat zu sichern und mit dem Datenbestand konsistent zu halten.

Reparatur der Such- und Verweisindizes

Eine wichtige Gruppe bei der Reparatur einer beschädigten Anwendung ist die Wiederherstellung von Verweisen und Suchindizes. Alle Verweise zwischen MCRObjects, MCRDerivates und MCRClassifications werden in der Tabelle MCRLINKHREFgespeichert. Dies ist eine sekundäre Tabelle. Sie kann gelöscht und wieder hergestellt werden. Gleiches gilt für den SOLR Suchindex. Auch er kann per Kommando gelöscht und neu aufgebaut werden.

Arbeiten am SOLR-Index

Die unten vorgestellten Kommandos gestatten ein reinidzieren des SOLR-Suchindex. Dies kann bei laufender Anwendung erfolgen, da der SOLR-Server eine applikationsunabhängige Instanz darstellt. Ein teilweises Reinidizieren erfolgt mit:

mycore.sh rebuild solr metadata index

mycore.sh rebuild solr content index

mycore.sh restricted rebuild solr metadata index for objecttype {0}

mycore.sh restricted rebuild solr metadata index for object {0}

mycore.sh restricted synchronize metadata index for objecttype {0}

Anschließend kann der SOLR-Index wieder optimiert werden.

mycore.sh optimize solr index

mycore.sh synchronize metadata index

Ggf. kann dieser auch komplett gelöscht und dann neu angelegt werden. Die dazu erforderlichen Kommandos sind:

mycore.sh drop solr index

mycore.sh rebuild solr metadata and content index

mycore.sh drop solr classification index

mycore.sh rebuild solr classification index

Auch einzelne Teile des Index können per Kommando gezielt gelöscht werden.

mycore.sh delete from solr index for type {0}

mycore.sh delete from solr index by id {0}

Neben den Auswahlmöglichkeiten über MyCoRe-ID und Objekt-Type besteht auch die Möglichkeit eines Selects über eine SOLR-Suche und die Nutzung des Ergebnisses zur Weiterverarbeitung.

mycore.sh select objects with solr query {0}

mycore.sh restricted rebuild solr metadata index for selected

mycore.sh restricted rebuild solr content index for selected

Zum Schluss noch die Möglichkeit, eine neue URL für den SOLR-Server zu setzen.

mycore.sh set solr server {0}

Diese Möglichkeit sollte jedoch nur in Ausnahmefällen genutzt werden, da sie ggf. je nach Datenmenge länger dauern könnte.

 Jens Kupferschmidt - 2016-05-11