GSB 7.0 Standardlösung

Springe direkt zu:

Zielgruppe BetriebVersion: GSB10.1Backup und Recovery

Dieses Dokument stellt Ansätze zum Backup und Recovery der persistenten Daten einer GSB Infrastruktur vor.

1 Einleitung

An dieser Stelle werden insbesondere die aus GSB Sicht zu sichernden Daten und Dateien und Ansätze und es wird ein Sicherungsverfahren für die verschiedenen Service-Typen skizziert.

Diese Dokumentation ist somit als allgemeine Dokumentation zu verstehen, macht aber keine konkreten Vorgaben für Datensicherungskonzepte, -verfahren und -tools, da diese in der Hoheit und Verantwortung des jeweiligen Plattformbetreibers liegen.

Diese Dokumentation ist somit Grundlage und Ausgangspunkt für die Erarbeitung und Etablierung eines Datensicherungsverfahrens einer Hostingplattform.

2 Statische Daten

In einer GSB Hostinginfrastruktur sind eine Reihe von statischen Dateien bzw. Sammlungen von statischen Dateien vorhanden, die bei der Definition eines plattformspezifischen Datensicherungskonzeptes zur berücksichtigen sind.

Unter statischen Daten werden an dieser Stelle Dateien verstanden, die zur Laufzeit der GSB Komponenten unverändert bleiben, so dass für die Sicherung dieser Daten keine Besonderheiten aufgrund von sich dynamisch ändernden Daten zu berücksichtigen sind.

2.1 GSB Releases

Grundlage für die Installation der GSB Komponenten sind die GSB-Releases. Hierbei kann es sich sowohl um GSB Produktreleases als auch Mandantenreleases handeln. Diese Releases sollten üblicherweise zentral abgelegt und bereitgestellt werden.

Die exemplarische Infrastrukturdefinition des GSB Produktrelease sieht vor, dass diese im Ordner releases des Benutzers gsbos abgelegt werden, so dass in diesem Fall die Sicherung des entsprechenden Ordners hinreichend ist, um alle GSB Releases zu sichern.

Hinweis:
Sollten die Releases aus organisatorischen Gründen auf verschiedenen Servern bereitgestellt bzw. gespiegelt werden, dann ist eine einmalige Sicherung hinreichend. Ein Recovery auf einem beliebigen Server kann in diesem Fall aus der zentral erstellten Sicherung der GSB Releases durchgeführt werden.

2.2 Platform-Bundle

Aus den GSB Releases werden als Installationsvorbereitung die Platform-Bundles erzeugt. Die Platform-Bundles werden ausschließlich auf Basis der GSB Releases erstellt, so dass sich für die Erstellung und Bereitstellung der Bundles ebenfalls eine zentrale Ablage anbietet.

Die exemplarische Infrastrukturdefinition des GSB Produktrelease sieht vor, dass die Platform-Bundles im Ordner platformBundle des Benutzers gsbos abgelegt werden, so dass in diesem Fall die Sicherung des entsprechenden Ordners hinreichend ist, um alle Platform-Bundles zu sichern.

Die Platform-Bundles auf Basis von Konfigurationsdateien (gsbos_global.cfg, platformBundle.cfg, serviceTypes.cfg) generiert, die in der exemplarischen Infrastrukturdefinition im Verzeichnis config des Benutzers gsbos abgelegt sind. Diese Dateien sollten auf einer Hostingplattform zusätzlich gesichert werden ,da diese quasi das "Gedächtnis" für die Erstellung der Platform-Bundles sind.

Hinweis:
Sollten die Platform-Bundles aus organisatorischen Gründen auf verschiedenen Servern erstellt werden, dann ist eine einmalige Sicherung (bei gleicher Bundledefinition) hinreichend. Ein Recovery auf einem beliebigen Server kann in diesem Fall aus der zentral erstellten Sicherung der Platform-Bundles durchgeführt werden.

2.3 GSB Installation

Die GSB-Komponenten werden auf den einzelnen Servern installiert. Die exemplarische Infrastrukturdefinition und die Empfehlung sieht vor, dass die Installation der GSB Komponenten auf den einzelnen Servern unterhalb des Ordners /opt/gsbos/software durchgeführt wird.

Eine Datensicherung des software-Ordners erscheint nicht erforderlich, da im Falle eines Recovery einfach eine erneute GSB Installation des aktuellen Platform-Bundle durchgeführt werden kann.

2.4 Laufzeitkonfiguration

Die Laufzeitkonfiguration der einzelnen GSB Instanzen (Service-Typen) wird in der exemplarischen Infrastrukturdefinition im Ordner /opt/gsbos/runtime abgelegt. Dieser Ordner sollte gesichert werden, da hier jeweils die individuellen Konfigurationen der einzelnen GSB Service-Typen definiert sind.

Hinweis:
Wenn die Laufzeitkonfigurationen der GSB Server einer Hostingplattform aus einem Konfigurationsmanagementsystem (CMDB), o.ä. generiert werden können, dann kann an dieser Stelle auch auf die Sicherung der Laufzeitkonfiguration verzichtet werden.

2.5 Beistellungen

Die Beistellungen des Systembetriebs für den Start und Betrieb der GSB Komponenten auf einer Hostingplattform werden an dieser Stelle nicht gesondert berücksichtigt, da diese üblicherweise über die vorhandenen Automatisierungs- und Provisionierungstools der Hostingplattform automatisch auf die Server verteilt und installiert werden. Ein Recovery der Beistellungen kann dann ebenfalls durch die erneute Provisionierung der Tools auf die Server durchgeführt werden.

3 Dynamische Daten

Im Gegensatz zu den im vorherigen Kapitel vorgestellten (statischen) Daten ändern sich die dynamischen Daten zur Laufzeit der GSB Komponenten. Eine Datensicherung der dynamischen Daten erfordert somit Maßnahmen, um einen konsistenten und in sich abgeschlossenen Stand der jeweiligen dynamischen Daten zu sichern.

3.1 Datenbanken

Eine Reihe von GSB Komponenten nutzt eine relationale Datenbank zur Speicherung der komponentenspezfischen Daten. Für jede Komponente (bspw. Adminportal, Site) bzw. jede Instanz (bspw. Preview-Repository, Master-Repository) wird eine dedizierte Datenbank bzw. Datenbanknutzer eingesetzt.

Die Sicherung der einzelnen Datenbanken für die jeweiligen GSB Dienste sollte jeweils pro Dienst erfolgen, da so eine einfachere Kontrolle des Sicherungsprozesses eines Dienstes durchgeführt werden kann.

In den folgenden Unterkapiteln werden Tools bzw. Hinweise zur Sicherung der beiden unterstützten Datenbanken MySQL und Oracle vorgestellt. Alternativ können natürlich auch die auf einer Hostingplattform etablierten Tools und Verfahren zur Datenbanksicherung eingesetzt werden.

3.1.1 MySQL-Datenbank Sicherung

Die für MySQL zur Verfügung stehenden Backup-Methoden sind in der MySQL-Dokumentation im Detail beschrieben (s.a. https://dev.mysql.com/doc/refman/5.7/en/backup-methods.html). Insbesondere bei Einsatz der MySQL Enterprise Edition kann mit dem Enterprise Backup eine Online-Sicherung der MySQL-Datenbanken durchgeführt werden, so dass für ein Backup einer Datenbank oder aller Datenbanken des Servers kein Stop des Servers durchgeführt werden muss.

Die GSB/OS Datenbanken werden als InnoDB im MySQL-Server eingerichtet, so dass eien Sicherung auch mit Hilfe der Methoden auf https://dev.mysql.com/doc/refman/5.7/en/innodb-backup.html durchgeführt werden kann. Ein Cold-Backup ermöglicht bei gestopptem Datenbank-Server bspw. eine explizite Sicherung einer Datenbank (s.a. Kapitel Cold Backups).

Eine Alternative zu MySQL Enterprise Edition ist der Einsatz des Open-Source Tools Percona Xtra Backup, welches ebenfalls eine Online-Sicherung ermöglicht. Details zum Backup finden sich in der Dokumentation auf der Seite https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html.

3.1.2 Oracle-Datenbank Sicherung

Eine Sicherung von Oracle-Datenbanken kann mit dem Oracle Tool RMAN durchgeführt werden. Eine gute Einführung in Konfiguration und Nutzungsmöglichkeiten von RMAN findet sich bspw. auf http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/rman_i_backup/index.html.

3.1.3 Datenbankinstanzen

Die folgenden Datenbankinstanzen sind unter dem Gesichtspunkt des Backups und Recovery relevant.

3.1.4 Adminportal

Die Sicherung des Adminportals kann ausschließlich durch Sicherung der Datenbank adminportal durchgeführt werden. Der Solr-Suchindex und Timestamp des zugehörigen Service-Tomcats müssen nicht gesichert werden, da diese im Falle eines Recovery aus einfach durch Index Neuaufbau wiederhergestellt werden können.

3.1.5 Maildistributor

Der Maildistributor verwaltet seine Informationen ausschließlich in der zugrundeliegenden Datenbank maildistributor, so dass an dieser Stelle eine Sicherung der Datenbank durchgeführt werden sollte.

Neben der Sicherung der Maildistributor-Datenbank sollte auch der Timestamp des zugehörigen EventDispatchers gesichert werden.

Vor dem Auslesen des Zeitstempels sollte die EventDispatcher-Webapplikation außer Betrieb. gesetzt werden, bzw. in den Offline-Modus versetzt werden, damit die weitere Event-Verarbeitung gestoppt wird und der Zeitstempel nicht mehr geändert wird. Die außer Betrieb Setzung wird per JMX mit dem folgenden MBean durchgeführt:

ObjectName:
de.bund.gsb.eventdispatcher:name=Status
ClassName:
de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatus
Method:
void setOffline();

Nachdem der EventDispatcher in den Offline-Modus versetzt worden ist, wird die Datenbank mit dem Namen maildistributor gesichert.

Zur Sicherung des EventDispatcher-Status wird der Zeitstempel des zuletzt verarbeiteten Content-Events ausgelesen. Das Auslesen des Zeitstempels erfolgt per JMX.

ObjectName:de.bund.gsb.eventdispatcher:name=StatusClassName:de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatusMethod:longObjectName:
de.bund.gsb.eventdispatcher:name=Status
ClassName:
de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatus
Method:
long getTimestamp();

Die Wiederherstellung des EventDispatcher-Status im Zuge des Recovery erfolgt erneut per JMX, indem der zuvor gesichert Timestamp wieder eingespielt wird (Methode setTimestamp).

Auch für das Recovery sollte die EventDispatcher-Webappliktions in den Offline-Modus versetzt worden sein (s.o.). Nach der Einspielung des gesicherten Timestamps kann die Webapplikations wieder in den Online-Modus versetzt werden, damit der EventDispatcher seinen Betrieb wiederaufnimmt und mit der Event-Verarbeitung ab dem Zeitpunkt des wiederhergestellten Timestamps startet.

Für das Setzen des Online-Modus wird das folgende MBean gentutzt:

ObjectName:
de.bund.gsb.eventdispatcher:name=Status
ClassName:
de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatus
Method:
void setOnline();

3.1.6 Workflow

Die redaktionellen Workflow-Instanzen der Camunda-Applikation werden unabhängig vom Content-Repository der Redaktion in einer dedizierten relationellen Datenbank gespeichert. Die in der Datenbank verwalteten Informationen umfassen ausschließlich Camunda-Metadaten und Informationen zu den GSB Workflows, so dass das Volumen der zugrundeliegenden Datenbank sehr überschaubar sein ist und eine Sicherung der Datenbank somit kein größeres Problem darstellen sollten.

Da die Publikationsmengen, die sogenannten ChangeSets, der Publikationsworkflows im Redaktions-Repository gespeichert werden, empfiehlt es sich die Sicherung der Datenbank der Workflow-Instanzen im Zuge der Backups des Redaktions-Repositories durchzuführen.

Die Workflow-Instanzen sollten während der Sicherung gestoppt sein, da ansonsten per Zeitsteuerung laufende Workflows Veränderungen an den Daten vornehmen könnten.

Bei der zu sichernden Workflow-Datenbank handelt es sich um die Datenbank mit dem Namen workflow.

3.2 Repository

Das Repository persistiert die redaktionellen Inhalte im lokalen Filesystem. Jede Repository-Instanz verfügt hier über einen eigenen Datastore, so dass für die Sicherung aller Repositories die einzelnen Datastores zu sichern sind.

Die exemplarische Infrastrukturdefinition sieht folgende Repository-Instanzen vor:

  • repository-preview: Content-Repository des Redaktionssystems. D.h. in diesem Repository werden die aktuellen Stände der GSB-Dokumente sowie deren Bearbeitungshistorie gespeichert.
  • repository-master: Content-Repository des Master-Livesystems. In dieses Repository werden die publizierten Inhalte aus dem Redakionssystem übertragen. Das Master-Repository verteilt diese anschließend an die angebundenen Replication-Livesysteme/-Repositories weiter. Das Master-Repository enthält ausschließlich publizierte Dokumente im publizierten Stand. D.h. eine Dokumenthistorie ist im Master-Repository nicht verfügbar.
  • repository-replication Content-Repository des Replication-Livesystems. Replication-Server werden in einer GSB Infrastruktur zur Erhöhung der Redundanz und/oder Performancesteigerung in der Live-Auslieferung eingesetzt. Der Inhalt des Replication-Repositories entspricht damit dem des Master-Repositories. Auf eine dedizierte Sicherung der Replication-Repositories kann an dieser Stelle daher verzichtet werden, da diese aus der Sicherung des Master-Repositories wiederhergestellt werden können.

Das Basisverzeichnis des Datastores der Content-Repositories ist in der Runtime-Property repository.storage.basedir definiert (Datei: application.properties). Die exemplarische Runtime des Repository-Preview definiert /space/gsbos/data/repository-preview als Basisverzeichnis für die Speicherung des Repositories.

Achtung:

Die Content-Publikation wird ausgehend vom Repository des Redaktionssystems über das Repository des Master-Servers an die Repositories der Replication-Server durchgeführt. D.h. der aktuellste Stand des Content liegt immer im Repository des Redaktionssystems vor. Master- und Replication-Repositories werden bei Publikation (zeitversetzt) aktualisiert.

Es bietet sich an, bei der Erstellung der Backups der Repositories die skizzierte Reihenfolge zu berücksichtigen. D.h. es sollten zunächst die Backups der Live-Repositories erstellt werden und anschließend ein Backup des Repositories des Redaktionssystems. So wird sichergestellt, dass im K-Fall bei Ausfall/Verlust der gesamten GSB-Infrastruktur die Repositories einfach wiederhergestellt werden können.

Bei einem Recovery des Master-Repositories aus dem Backup werden evtl. fehlende Publikationen automatisch republiziert. D.h. der Contentserver ermittelt den Stand der Publikation im Master-Server und gleicht diesen mit dem Stand im Redaktionssystem ab. Im Master-Server fehlende Publikationen werden anschließend automatisch durch das Redaktionssystem nachgespielt, so dass Redaktionssystem und Master-Server auf denselben Stand gebracht werden.

Als abschließende Aktionen werden ggf. fehlende Publikationen dann noch vom Master- auf die Replication-Server repliziert.

Die Repositories in der Live-Umgebung sind aus Backup-Sicht besonders, da alle Repositories denselben publizierten Contentstand enthalten sowie aus technischer Sicht gleich aufgebaut sind. In einer laufenden Infrastruktur kann bei einer Publikation von Content lediglich zu kleineren Unterschieden kommen, da der publizierte Content vom Master-Server mit einer geringen zeitlichen Verzögerung auf die angebundenen Replication-Server repliziert werden.

Hinweis:

In der Liveumgebung sind das Master-Repository sowie n-Instanzen von Replication-Repositories vorhanden. Die Repositories der Replication-Server entsprechen denen des Master-Servers, so dass eine Sicherung der Replication-Repositories nicht zwingend erforderlich ist.Im Recovery-Fall kann ein Replication-Repository aus der letzten Sicherung des Master-Repositories wiederhergestellt werden.

Alternativ kann ein Recovery eines Repositories auch aus dem aktuellen Stand eines anderen Live-Repositories wiederhergestellt werden. D.h. ein Recovery eines Live-Repositories muss nicht zwingend aus einem Backup desselben Repositories wiederhergestellt werden, sondern es kann ein anderes Live-Repository in der Infrastruktur als Grundlage für das Recovery genutzt werden.

3.2.1 Vorgehen zur Offline Sicherung

Um sicherzustellen, dass das zu sichernde Contentrepository in einem konsistenten Zustand ist empfiehlt es sich, das betreffende Repository zunächst zu stoppen. D.h. der Content-Server (Service-Instanz repository-preview) wird bspw. mit dem folgenden Kommando gestoppt:

sudo systemctl stop repository@repository-preview

Nachdem das Repository gestoppt worden ist, kann die Sicherung des Datastores mit den auf der Hostingplattform zur Verfügung stehenden Tools für die Filesystemsicherung gesichert werden. Dazu stehen die "Oak Run" Tools zur Verfügung, welche von der Kommandozeile aus aufgerufen werden. Zum Erstellen eines Backups sieht der Aufurf wie folgt aus:

java -jar oak-run-*.jar backup <repository> <backup>

Weitere Informationen zu den Kommandozeilen-Tools können der Jackrabbit Oak Dokumentation entnommen werden: https://jackrabbit.apache.org/oak/docs/command_line.html

Nachdem die Sicherung abgeschlossen ist, wird das Repository wieder gestartet:

sudo systemctl start repository@repository-preview

Hinweis:

Für eine zusätzliche Sicherung des aktuellen Standes eines Content-Repositories bietet sich eine Sicherung des Contents über einen vollständigen Content-Export an. Ein Export des publizierten Contents des Master-Repositories kann bspw. mit dem folgenden curl-Kommando durchgeführt werden:

curl --silent -o /space/gsbos/backup/publishedContent`date '+\%Y-\%m-\%d'`.zip http://localhost:7001/content/exporter/zip?path=/

Das Kommando exportiert alle Dokumente des Master-Content-Repositories (path=/`) des lokal auf dem System laufenden Content-Repositories (localhost:7001). Der Port 7001 entspricht dem Port auf dem das Master-Content-Repository läuft.

3.2.2 Vorgehen zur Online Sicherung

Soll eine Sicherung im laufenden Betrieb erfolgen, kann diese Sicherung mit Hilfe der Gsb Shell angestoßen werden.

Das Backup wird mit dem Kommando backup in der Gsb Shell angestoßen. In der Runtime-Property repository.segmentNodeStore.backupdir wird das Basisverzeichnis für das Backup definiert. Das Backup wird mit Hilfe der Jackrabbit internen Backup-Mechanismen als vollwertiges Jackrabbit Contentrepository erstellt.

Nachdem das Backup des Repositories erstellt worden ist, kann dieses mit dem zugrundliegenden Backup-Tool des Betriesbssystems/Hostingplattform-Betreibers zusammen mit dem Blobstore des Repositories gesichert werden.

Der Blobstore liegt bei Verwendung der exemplarischen Runtime-Konfiguration im Ordner /space/gsbos/data/repository-preview/oak/blobs (für das Repository des Redaktionssystems).

3.3 Solr-Suchindeces

Die Sicherung der Solr-Suchindices sollte als Offline-Sicherung durchgeführt werden, um Inkonsistenzen aufgrund von Änderungen im Suchindex während des Backups ausschließen zu können. Zunächst wird daher der Indexer in den Offline-Modus versetzt. Dies kann entweder über die Administrationsoberfläche der Indexer-Webapplikationen erfolgen oder per JMX.

Im Offline-Modus werden von dem Indexer keine weiteren Content-Events empfangen und verarbeitet, wodurch auch keine Veränderungen am Solr-Suchindex vorgenommen werden.

Nach der Offline-Setzung des Indexers kann der Status (der Timestamp) des Indexers per JMX abgefragt und gesichert werden. Das folgende MBean kann für das Setzen des Online-Status verwendet werden.

ObjectName:
de.bund.gsb.indexer:name=Status
ClassName:
de.bund.gsb.indexer.mbeans.IndexerOnlineStatus
Method:
void setOffline(); setOffline();

Im Anschluss wird die Solr-Instanz gestoppt. Hierbei ist zu beachten, dass die Solr-Instanz noch Informationen, die zu einer Veränderung des Suchindex beitragen, in der Verarbeitungswarteschleife vorhält. Diese Informationen können durch das Stoppen verloren gehen. Ob dies der Fall ist kann innerhalb der Übersicht eines Solr-Kerns über den Status „Current“ überprüft werden (siehe Abbildung).

Zur Sicherung der auf dem Dateisystem gespeicherten Suchindizes wird von diesen zunächst eine Kopie angelegt werden. Diese Kopie kann dann zur Sicherung verwendet werden, um die Solr-Instanz zeitnah wieder in Betrieb nehmen zu können.

Die zu sichernden Daten der Suchindizes sind im Datenverzeichnis der Solr-Tomcat-Instanz im „solr-data“-Verzeichnis zu finden (Verzeichnis /space/gsbos/data/solr-master). Das „solr-data“-Verzeichnis ist wie folgt aufgebaut:

solr-data
|-- standardlsg
| |-- index
| |-- spellchecker
| |-- tlog
|-- standardlsg_editor
| |-- index
| |-- spellchecker
| |-- tlog
|-- standardlsg_functions
| |-- index
| |-- spellchecker
| |-- tlog
|-- customer2
| |-- index
| |-- spellchecker
| |-- tlog
|-- ...solr-data|-- standardlsg| |-- index| |-- spellchecker| |-- tlog|-- standardlsg_editor| |-- index| |-- spellchecker| |-- tlog|-- standardlsg_functions| |-- index| |-- spellchecker| |-- tlog|-- customer2| |-- index| |-- spellchecker| |-- tlog|-- ...

Jeder Solr-Kern eines Mandanten, bzw. eines funktionalen Mandanten (<CUSTOMER>_editor, <CUSTOMER>_functions), liegt in einem separaten Verzeichnis.

Im Rahmen der Sicherung der Solr-Suchindizes wird ebenfalls der Indexer-Status berücksichtigt. Der Indexer, welcher die Suchindizes einer Solr-Instanz befüllt, hält seinen Status in Form eines Timestamps, der den zuletzt verarbeiteten Content-Event entspricht. Für eine konsistente Sicherung der Solr-Indizes muss daher der zum Zeitpunkt der Sicherung aktuelle Timestamp mit gesichert werden. Dieser kann mit dem folgenden MBean per JMX ermittelt und mit gesichert werden:

ObjectName:
de.bund.gsb.indexer:name=Status
ClassName:
de.bund.gsb.indexer.mbeans.IndexerOnlineStatus
Method:
long gestTimestamp();

Nachdem die Sicherung der Solr-Indices durchgeführt worden ist, wird der zugehörige Indexer mit dem folgenden MBean wieder gestartet:

ObjectName:
de.bund.gsb.indexer:name=Status
ClassName:
de.bund.gsb.indexer.mbeans.IndexerOnlineStatus
Method:
void setOnline();

Wird der von Solr bereitgestellte Replikationsmechanismus eingesetzt, reicht es die Master-Solr-Instanz zu sichern. Die Indexe der Replikationsinstanzen werden dann nach dem Recovery eines Master-Solr-Indexes automatisch von der Master-Instanz befüllt.

3.4 Service-Tomcat

Im Service-Tomcat der Redaktion werden die beiden Webapplikationen Indexer und EventDispatcher betrieben. Die Sicherung des Indexers (Timestamp) wird bei der Sicherung der Solr-Indices betrachtet (s.a. Kapitel „Solr-Suchindex“), so dass an dieser Stelle eine Sicherung des EventDispatcher-Status dokumentiert wird.

Vor dem Auslesen des Zeitstempels sollte die EventDispatcher-Webapplikation außer Betrieb. gesetzt werden, bzw. in den Offline-Modus versetzt werden, damit die weitere Event-Verarbeitung gestoppt wird und der Zeitstempel nicht mehr geändert wird.

Die außer Betrieb Setzung wird per JMX mit dem folgenden MBean durchgeführt:

ObjectName:
de.bund.gsb.eventdispatcher:name=Status
ClassName:
de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatus
Method:
void setOffline();

Zur Sicherung des EventDispatcher-Status wird der Zeitstempel des zuletzt verarbeiteten Content-Events ausgelesen. Das Auslesen des Zeitstempels erfolgt per JMX.

ObjectName:
de.bund.gsb.eventdispatcher:name=Status
ClassName:
de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatus
Method:
long getTimestamp();

Die Wiederherstellung des EventDispatcher-Status im Zuge des Recovery erfolgt erneut per JMX, indem der zuvor gesichert Timestamp wieder eingespielt wird (Methode setTimestamp).

Auch für das Recovery sollte die EventDispatcher-Webappliktions in den Offline-Modus versetzt worden sein (s.o.). Nach der Einspielung des gesicherten Timestamps kann die Webapplikations wieder in den Online-Modus versetzt werden, damit der EventDispatcher seinen Betrieb wiederaufnimmt und mit der Event-Verarbeitung ab dem Zeitpunkt des wiederhergestellten Timestamps startet.

Für das Setzen des Online-Modus wird das folgende MBean genutzt:

ObjectName:
de.bund.gsb.eventdispatcher:name=Status
ClassName:
de.bund.gsb.eventdispatcher.mbeans.EventDispatcherOnlineStatus
Method:
void setOnline();