Wiederherstellung nach einem beschädigten Versionsverlauf

Ein inkonsistenter Versionsverlauf kann zu Fehlfunktionen vieler CQ-Vorgänge führen, einschließlich Replikation, Versionswiederherstellung und Installation von Inhaltspaketen.

Wenn ein Versionsverlauf fehlerhaft ist, wird in den Protokolldateien die Ausnahme org.apache.jackrabbit.core.state.NoSuchItemStateException angezeigt. Und Sie sehen das Gleiche in den Stacktrace-Klassen (Stacktrace = „Stapel(speicher)zurückverfolgung“) aus dem Paket org.apache.jackrabbit.core.version.

Lösung

Verwenden Sie den Systemparameter “org.apache.jackrabbit.version.recovery:”

Um den Parameter anzuwenden, gehen Sie wie folgt vor:

1. Installieren Sie den neuesten Hotfix für CRX2.2. Sie können den neuesten CRX-Hotfix anfordern, indem Sie ein Supportticket senden. Befolgen Sie die Hotfix-Installationsanweisungen und stellen Sie sicher, dass CQ nach der Installation neu gestartet wird.
   
2. Beenden Sie CQ/CRX.
3. Fügen Sie dem Startskript den Parameter jvm hinzu: -Dorg.apache.jackrabbit.version.recovery=true
4. Starten Sie CQ/CRX.
5. Überprüfen Sie den Java-Prozessstatus (z. B. ps -ef | grep java), um sicherzustellen, dass der neue Parameter verwendet wird.

Wenn diese Funktion aktiviert ist, sucht sie nach allen versionierbaren Knoten im Repository und überprüft, ob der jeweilige Versionsverlauf vorhanden ist.

Wenn dies nicht der Fall ist, entfernt die Wiederherstellungsprozedur den fehlerhaften Verweis auf den Versionsspeicher. Insbesondere das mix:versionable Mixin und die Eigenschaften jcr:versionHistory, jcr:baseVersion, jcr:predecessors und jcr:isCheckedOut. Es ermöglicht dem Repository, ein neues Versionsdiagramm für den Knoten zu erstellen, zum Zeitpunkt, wenn es benötigt wird.

Wenn sich die fehlenden Knoten auf der Stammebene befinden, sind die Inkonsistenzen des Versionsarbeitsbereichs nicht reparierbar. In diesem Fall ist es notwendig, mit einem neuen Datensatz der neuen Version zu beginnen. Ihre einzige Möglichkeit, frühere Daten aus der Version wiederherzustellen, besteht darin, ein Backup zu verwenden. Anschließend können Sie das Paket verwenden, sobald die Version wiederhergestellt wurde.   Wenn Sie den Versionsordner entfernen müssen (der beim Start automatisch neu erstellt wird), ist ein wichtiger Inhalt Ihr Workflow-Modus. Nach dem Neustart (mit dem obigen jvm-Parameter) können Sie dann ein Paket installieren, das das Workflowmodell in die Version zurücksetzt. Alle Workflowinstanzen, die nicht abgeschlossen wurden, können nicht weiter verarbeitet werden, da die Versionsinformationen mit der Workflowinstanz verknüpft sind. (Siehe die zugehörige Eigenschaft im Workflowinstanzknoten.) Wenn diese Modellversion fehlt, kann sie nicht weiter verarbeitet werden (es muss manuell behoben werden).   Stellen Sie vor dem Ausführen der folgenden Schritte sicher, dass alle Workflows abgeschlossen sind. (Wenn eine Instanz ausgeführt wird, sind zusätzliche Aktionen mit einem benutzerdefinierten Skript erforderlich, um den Verweis auf die Version des Workflow-Instanzmodells auf die neue zurückzusetzen.)

1. Stoppen Sie die Instanz.
2. Löschen Sie den Versionsordner und den Ordner repository/repository/index.
3. (Optional) Fügen Sie in der crx.default workspace.xml für die Tar Persistence Manager-Daten „consistency/check fix“ hinzu.
4. Fügen Sie -Dorg.apache.jackrabbit.version.recovery=true hinzu.
5. Starten Sie die Instanz. Dies kann mehrere Stunden oder Tage dauern, je nach Menge der Daten und I/O-Performance. Ziehen Sie daher in Erwägung, zuerst auf einer Kopie zu testen.
   
6. Wenn die Instanz fertig ist, erstellen Sie ein Paket aus /etc/workflow/models.
7. Löschen Sie die /etc/workflow/models (mit CRXDE oder CRX Explorer).
8. Installieren Sie das soeben erstellte Paket drüber, um die Workflowmodelle neu zu erstellen.

Hinweis: Beginnend mit CRX 2.2 hilft der im folgenden Artikel beschriebene Parameter, Inkonsistenzen zu vermeiden.