CSSCurrent de:Datenbank Migration
Allgemeine Hinweise
In diesem Update wird die bisher verwendete OrientDB-Datenbank durch eine neue H2-Datenbank ersetzt. Um weiterhin alle versendeten Transfers abrufen zu können, werden diese und auch alle getroffenen Einstellungen von der alten Datenbank in die neue migriert. Die Migration wird automatisch während des Postupdate-Schrittes durchgeführt, sodass im Regelfall für den Administrator kein weiterer Aufwand entsteht (siehe unten).
Voraussetzungen für Appliances
Voraussetzungen für selbstinstallierte SystemeWas sind die Vorteile der neuen Datenbank?
Die neue Datenbank ist zuverlässiger, aufgrund der Verwendung einer anderen Datenbank-Engine, signifikant schneller und weiter verbreitet als die OrientDB-Datenbank. Sie bietet geringe Speicher- und Prozessoranforderungen. Durch die Verwendung datenbankeigener Techniken kann die Datenintegrität noch besser gewährleistet werden. Zusätzlich entfallen datenbankspezifische Verarbeitungsschritte, sodass sich die Geschwindigkeit verschiedenster Vorgänge erhöht. Ebenso unterstützt die Datenbank eine größere Zahl von gleichzeitigen Zugriffen und ist somit für viele parallel laufende Transfers noch besser geeignet.
Welche Änderungen bringt das Datenbankupdate mit sich?
Veränderte Konfiguration
- Die Konfiguration der Poolgröße bei hoher Auslastung hat sich verändert. Details erfahren Sie im Artikel Konfiguration der Datenbank.
- Die Erweiterte Cryptshare-Konfiguration wurde um jene Parameter bereinigt, die nicht mehr für den Betrieb der neuen Datenbank notwendig sind.
Veränderte Verzeichnisstruktur
Alle Dateien, die zur Verwendung der orientDB-Datenbank notwendig waren, befanden sich im orientDB-Unterverzeichnis des Cryptshare-Installationsverzeichnisses. Während der Datenbankmigration wird die neue Datenbank in das Unterverzeichnis db geschrieben. Beachten Sie, dass wenn Sie die bisherige orientDB-Datenbank auf einer anderen Festplatte per Verknüpfung eingebunden haben, dass Sie diese Verknüpfung vor der Migration auch auf das db-Verzeichnis anwenden sollten.
Wie viel Zeit nimmt die Migration in Anspruch?
Die Migration der Daten hängt vor allem von der Zahl der bisher versendeten Transfers ab. Der Vorgang kann zwischen einigen Minuten bis hin zu einer Stunde dauern.
Werden alle Daten in die neue Datenbank übertragen?
Transfers, die seit mehr als 12 Monaten abgelaufen sind und Adressbucheinträge (bei der Eingabe der Empfänger in der Web App), die seit mehr als 12 Monaten nicht mehr verwendet wurden, werden nicht in die neue Datenbank importiert. Dies bedeutet, dass Statistikdaten, die älter als 12 Monate sind, nach der Aktualisierung nicht mehr verfügbar sind. Das Transferlog umfasst nach der Migration lediglich jene Transfers, die noch nicht oder innerhalb der letzten 12 Monate abgelaufen sind. (Wenn Sie die vorherige Version wiederherstellen, so können Sie das Transferlog für vergangene Transfers als CSV exportieren: siehe Log-Ansicht).
Welche Fehler können bei der Datenmigration auftreten?
Eine Migration kann mit drei verschiedenen Zuständen beendet werden:
- Erfolgreich
- Migration mit Warnungen
- Fehlgeschlagene Migration
Erfolgreiche Migration
Welche Möglichkeiten bestehen in diesem Fall?
- Das Postupdate kann abgeschlossen werden, ohne dass die Notwendigkeit besteht, Einstellungen und Policyregeln auf ihre Korrektheit hin zu überprüfen. Nach einem Serverneustart kann Cryptshare direkt mit der neuen Datenbank verwendet werden.
- Selbstverständlich ist es auch möglich, die vorherige Cryptshare Version wiederherzustellen.
Was sind die Konsequenzen?
Wenn Sie das Postupdate abschließen, verwenden Sie direkt die neue Datenbank. Wie oben erwähnt, werden alle Transfers, die seit mehr als 12 Monaten abgelaufen und somit nicht mehr abrufbar sind, gelöscht und werden nicht mehr in der Statistik und im Transfer-Log berücksichtigt.
Migration mit Warnungen
Welche Möglichkeiten bestehen in diesem Fall?
Informationen im Migrationslog
Grundsätzlich empfehlen wir in diesem Fehlerfall immer, die Logdatei 'Cryptshare-Datenbank-Migration' einzusehen. In der Logdatei können bei später auftretenden Fragen von Absendern oder Empfängern jene Transfers nachgeschlagen werden, bei deren Migration Probleme aufgetreten sind. Nachdem Sie die Logdaten analysiert haben, steht es Ihnen frei, den Updateprozess fortzusetzen und den Cryptshare-Betrieb unter den genannten Bedingungen wieder aufzunehmen. Sollten Sie sich unsicher sein, oder möchten die Risiken nicht in Kauf nehmen, ist es möglich die Installation wieder auf die vorhergehende Cryptshare Version zurückzusetzen.
Einstellungen und Policyregeln konnten nicht migriert werden
In vereinzelten Fällen kann es vorkommen, dass Einstellungen und Policyregeln nicht migriert werden können. Bitte überprüfen Sie aus diesem Grund nach der Durchführung des Postupdates in der Administrationsoberfläche alle Einstellungen. Die folgenden Beispiele zeigen einen Auszug der Logdatei, der auf einen solchen Fehler hindeuten: `WARN 2020-01-01 09:00:00 BaseEntityHandler - Required property 'Verification code validity` `' for entity 'VerificationSettings' missing! Setting default to '15' ` Diese Meldung weist darauf hin, dass die Einstellung 'Verification code validity' nicht übertragen werden konnte. Korrigieren lässt sich dies nach Abschluss des Updates manuell über die Administrationsoberfläche unter "System-Settings" → "Verification". `WARN 2020-01-01 09:00:00 BaseEntityHandler - Property 'Sender Address' for entity 'PolicyRule' is too long (max length '320'). Cut off value!` Diese Meldung weist darauf hin, dass die Einstellung 'Sender Address' einen zu langen Wert aufweist und deshalb gekürzt wird. Korrigieren lässt sich dies nach Abschluss des Updates manuell über die Administrationsoberfläche unter "System-Settings" → "Policy Einstellungen". `WARN 2020-01-01 09:00:00 BaseEntityHandler - Property 'SMTP Password' for entity 'MailSettings' is too long (max length '4000'). Clear value!` Diese Meldung weist darauf hin, dass die Einstellung 'SMTP Password' einen zu langen Wert aufweist und deshalb entfernt wird. Korrigieren lässt sich dies nach Abschluss des Updates manuell über die Administrationsoberfläche unter "System-Settings" → "Mail Server Einstellungen".
Verlust von Transferdaten
In einzelnen Fällen kann es vorkommen, dass Transferdaten oder QUICK Verbindungsdaten nicht migriert werden können, da sie bereits beschädigt sind. Betroffene Transfers sind nach der Migration nicht mehr abrufbar und können von der Statistik nicht erfasst werden. Beschädigte QUICK Verbindungen müssen neu aufgebaut werden. Eine Übersicht darüber, wie viele Transfers und QUICK-Verbindungen migriert werden konnten, findet sich in der Logdatei:
Beispiel: Anzahl der migrierten Transferdatensätze INFO 2020-01-01 09:00:00 TransferEntityHandler - Successfully migrated 900 of 1000 'Transfer'. Optimized database and skipped 100 outdated entries.
In diesem Fall wurden 900 von 1000 Transfers migriert. Die verbliebenen 100 Transfers, die vor mehr als 12 Monaten abgelaufen sind und seitdem auch nicht mehr abgerufen werden können, wurden nicht migriert.
Was sind die möglichen Konsequenzen?
- Einzelne Einstellungen und Policyregeln wurden möglicherweise auf ihre Werkseinstellungen zurückgesetzt. Überprüfen Sie anhand der Logdatei, ob die gesetzten Werte Ihren Anforderungen entsprechen.
- Transfers, die nicht migriert werden konnten, sind nicht mehr abrufbar. Eine Auflistung mit dazugehöriger Tracking-ID ist in der Logdatei zu finden.
Fehlgeschlagene Migration
Welche Möglichkeiten bestehen in diesem Fall?
- Prüfen Sie in diesem Fall, ob die Maschine über genügend freien RAM verfügt. Für die Datenbankmigration werden mindestens 2 GB freier RAM benötigt.
- Ebenso sollte die Maschine über genügend freien Festplattenspeicher verfügen. Prüfen Sie, dass der im Cryptshare-Installationsverzeichnis verfügbare Speicherplatz mindestens der Größe des `orientDB`-Verzeichnisses entspricht. Für den weiteren Betrieb der Cryptshare-Anwendung sollten mindestens 2 GB freier Speicher verfügbar sein.
- Auf Linuxsystemen sollte der Nutzer csuser Schreib- und Leserechte auf das Cryptshare-Installationsverzeichnis und den möglicherweise bereits angelegten Unterordner `db` besitzen.
- Wenn Sie eines der oben genannten Probleme gelöst haben, so können Sie die Migration erneut starten.
Was sind die möglichen Konsequenzen?
- Wenn genügend freier Festplattenspeicher und RAM verfügbar waren, und dennoch die Migration fehlschlägt, so wenden Sie sich bitte an den Cryptshare-Support. Um Ihr Cryptshare-System vorerst weiter nutzen zu können, führen Sie eine Wiederherstellung auf eine vorherige Version durch.