Migrationsverfahren
Allgemein
Unter Migration versteht man bei PLANTA Anpassungen an der Datenbank, die für das Aktualisieren des Systems auf eine höhere Version erforderlich sind. Das Migrationsverfahren basiert auf in Python geschriebenen Migrationspaketen und ist in PLANTA integriert.
Migrationspakete führen Änderungen an der vorhandenen PLANTA-Installation, vor allem der Datenbank, durch.
Um die Migration zu starten, muss der Server im Migrationsmodus (siehe den Abschnitt weiter unten) gestartet werden.
Der Server startet eine neue interne Session mit dem PLANTA-Benutzer MIGRATION. Daher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer MIGRATION. Sie auch den Eintrag unter Achtung weiter unten.
Beim Starten der Migration werden alle Pflichtpakete automatisch ausgeführt. Alle weiteren Pakete müssen manuell ausgeführt werden. Hierzu siehe Hinweise im Abschnitt Migrationsmodus.
Werden der Benutzer MIGRATION und die ihm zugeordnete Person gelöscht, werden sie beim nächsten Update automatisch neu angelegt.
Um die Performance zu verbessern, wird für MSSQL-Systeme empfohlen, vor der Migration zu dem Recovery-Modell RECOVERY SIMPLE zu wechseln: ALTER DATABASE <PLANTA_DB_USER> SET RECOVERY SIMPLE
Nach erfolgter Migration sollte das Recovery-Modell wieder auf das ursprünglich eingestellte Modell zurückgesetzt werden. Dies ist das Standard-Modell der Datenbank.Welche Migrationspakete mit dem gewünschten Server- oder Datenbank-Release ausgeliefert werden, wird in Release Notes angegeben.
Wenn es Probleme gibt in der Art, dass vorhandene Python-Module nicht geladen werden können (z.B. im Migrationsskript 'FillMigrationRuleTable'), kann dies durch manuelles Ausführen des Pakets CreateFolderPacket im Modul Release-übergreifende Pakete behoben werden.
Update im Container
Um die Customizing-Komponente in der Container Umgebung upzudaten, wie folgt vorgehen:
Den folgenden Parameter in die Umgebungsvariablen im Manager-Container aufnehmen:
CODE- "UPDATE=1"Die gewünschte Version des Customizing-Image hinterlegen.
Den Container starten und nach dem Update den Parameter wieder entfernen.
Migrationsmodus
Der Server besitzt einen neuen Modus für die Durchführung der Migration, den sogenannten Migrationsmodus.
Im Migrationsmodus werden die vorhandenen Migrationspakete, bei denen der Parameter Bei Systemstart =
Error rendering macro 'fontawesome-macro' : Page loading failedsowie Erledigt =Error rendering macro 'fontawesome-macro' : Page loading failedsind, ausgeführt.Während sich der Server im Migrationsmodus befindet, kann sich kein Client mit diesem Server verbinden.
Nach Durchführung der Migration beendet sich der Server automatisch.
Die Migration wird durch Aufruf von
command: ["migration", "-c <Name der Parameterdatei>"]im Manager-Container gestartet.
Alternativ zum Migrationsmodus können Migrationspakete auch im Programm (an der Oberfläche) über folgende Module ausgeführt werden.
Nach Ausführen der Migrationspakete im System muss der Server bzw. der Server-Dienst neugestartet sowie die Migrationsergebnisse überprüft werden.
Technischer Ablauf
Die Migrationsparameter müssen in einer Parameterdatei enthalten sein.
- Error rendering macro 'fontawesome-macro' : Page loading failedDie Parameterdatei sollte nur von erfahrenen Benutzern erstellt und angepasst werden.
Eine Beispielparameterdatei befindet sich im Customizing-Container unter
config/migration/migration.par.
Das Kommando
migrationhat einen Pflicht-Parameter:-c/--migration-config.Dieser Parameter muss der (vom worker-Container relative) Pfad zur Migrationsparameterdatei sein.
- Error rendering macro 'fontawesome-macro' : Page loading failedEs dürfen keine Leerzeichen in diesem Pfad enthalten sein!
Um die Migration zu starten, muss das Kommando
command: ["migration", "-c <Name der Parameterdatei>"]in der docker-compose.yml im Manager-Container aufgenommen werden und der Container gestartet.- Error rendering macro 'fontawesome-macro' : Page loading failedMigrationsverfahren sollte nur von erfahrenen Benutzern gestartet werden.
Der Server startet eine neue interne Session mit dem PLANTA-Benutzer Migration.
- Error rendering macro 'fontawesome-macro' : Page loading failedDaher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer Migration.
- Error rendering macro 'fontawesome-macro' : Page loading failedBitte beachten Sie, dass aus diesem Grund der Benutzer Migration nicht gelöscht werden darf.
Es wird nach neuen Migrationspaketen auf dem Dateisystem gesucht, diese werden ausgeführt und Informationen darüber in der Datenbank abgespeichert.
Nachdem das Dateisystem durchsucht wurde, werden die Pakete ausgeführt.
Migrationsparameter
Die für die Migration erforderlichen Parameter werden in einer Parameterdatei angegeben.
Aufbau der Parameterdatei:
--migration-components
Server
Customizing-Hotfix
Customizing
Customer
Before DB Import
After DB Import
--abort-on-failure
--packets-to-exclude
--delete-demo-data
--change-license
--export-data
--export-schema
--container-update
--final-update
Sektion | Erklärung |
|---|---|
| Hier werden die Komponenten angegeben, die migriert werden sollen. Die "klassische" Migration mit Migrationspaketen startet nur wenn der Parameter |
| Ist diese Option vorhanden, wird die Migration abgebrochen, sobald ein Migrationspaket fehlschlägt. |
| Hier kann pro Zeile der absolute Pythonpfad zu einem Migrationspaket hinterlegt werden, welches bei der Migration nicht ausgeführt werden soll. Z.B.: |
| Wird dieser Parameter in die Datei aufgenommen, werden die Demodaten aus dem System entfernt. Error rendering macro 'fontawesome-macro' : Page loading failed Achtung: Bei der "Demodaten-Bereinigung" wird kein Filter auf die Owner-Lizenz oder Ähnliches gesetzt, sondern es werden einfach alle Tabellen mit Projekt/Benutzer/etc. Daten geleert (nur Benutzer P20 und MIGRATION verbleiben). Die Funktion muss am Anfang nach Aufsetzen eines Systems ausgeführt werden und kann nicht benutzt werden, um in einem System, welches bereits produktiv benutzt wurde, die Demodaten zu bereinigen! |
| Wenn angegeben, werden die Lizenzdatensätze im System geändert.
|
| Ruft den Datenbank-Export mit der übergebenen Parameterdatei auf. Beispiel:
CODE
|
| Ruft den Schema-Export auf und schreibt die Resultate in das übergebene Verzeichnis. Beispiel:
CODE
|
| Führt eine Migration in der Container-Umgebung durch. |
| Führt den finalen Lizenztausch aus. |
Die möglichen Komponenten stammen aus der
__init__.pyder jeweiligen MigrationsverzeichnisseDie angegebenen Komponenten bestimmen den Update-Typ der Migration. So ist es z.B. möglich, nur das Customizing zu migrieren oder nur die Server-Komponente.
Die Parameterdatei gibt nicht nur die Komponenten vor, die migriert werden sollen, sondern auch die Reihenfolge, in der migriert wird.
Alle Pakete, die nicht unter die Liste der angegebenen Komponenten fallen, erhalten den Status
Nicht relevant.
Individualisierungsmöglichkeiten
Es können auch individuelle Migrationspakete gecustomized werden.