Der ultimative Leitfaden zur Datenmigration in Mendix

In diesem Beitrag beziehe ich mich auf Quelle und Target Umgebungen. Quelle die aktuell ausgeführte Umgebung (die, von der wir weg wollen) und Target da es sich um unsere brandneue, selbstgehostete Umgebung handelt, in die wir Daten migrieren möchten.

Vorwand

Bevor wir beginnen, ist es wichtig, ein klares Verständnis davon zu haben, wie Daten verwaltet und gespeichert werden von Mendix. Mendix trennt Daten in zwei Bereiche: Datenbank und Dateispeicher.

Database

Die Datenbank spiegelt das in Studio Pro erstellte Domänenmodell wider und speichert alle erwarteten Informationen.

• Entitäten werden Datenbanktabellen zugeordnet
• Attribute werden Spalten in Tabellen zugeordnet
• Festgeschriebene Objekte werden den Zeilen in diesen Tabellen zugeordnet.

In Mendix Cloud, dies ist eine AWS Postgres-Datenbank.

Dateispeicher

Dateien hingegen werden separat gespeichert. Die Metadaten einer Datei (Dateiname, Größe, UUID) werden in der Datenbank gespeichert, der binäre Dateiinhalt selbst jedoch nicht – der binäre Inhalt wird gespeichert als Dateispeicher. Die UUIDs in der FileDocument-Datenbanktabelle entsprechen eins zu eins den Dateinamen des binären Inhalts. In Mendix Cloud: Dies wird als Objektspeicher auf AWS S3 gehostet.

Einleitung / Intro

Der Umfang dieses Tutorials ist die Daten- und Dateimigration einer Live-Umgebung. Es wird davon ausgegangen, dass die Zielumgebung eingerichtet ist, die Mendix Die Anwendung ist bereitgestellt und verfügt über eine konfigurierte (wenn auch leere) und funktionsfähige Datenbank und einen Dateispeicher.

Ausführliche Informationen zur Bereitstellung eines Mendix Anwendung können Sie Schauen Sie sich diese Anleitung an.

Bevor Sie eine Migration einer Live-Produktions-App durchführen, sollten Sie die folgende Checkliste durchgehen:

• Führen die Quell- und Zielumgebung genau die gleiche Version des Mendix App (.mda)? (Wenn nicht die gleiche Version verwendet wird, kann es zu Datenverlust kommen.)
• Wurde ein Migrationsfenster geplant und kommuniziert? (Die Migration einer Live-Anwendung erfordert Ausfallzeiten, normalerweise außerhalb der Geschäftszeiten. Planen Sie die Migration und informieren Sie die Benutzer, wenn auf die App nicht zugegriffen werden kann.)
• Wurde ein Snapshot-Datum vereinbart und den Benutzern mitgeteilt? (Für eine Migration muss zu einem bestimmten Zeitpunkt ein Sicherungs-Snapshot der Daten erstellt werden. Alle nachfolgenden Änderungen werden nicht migriert. Wenn es Zeit für die Migration ist, stoppen Sie die Live-Umgebung, erstellen Sie einen Daten-Snapshot und beginnen Sie.)
• Üben Sie den Wiederherstellungsprozess in einer Wegwerfumgebung, bevor Sie ihn tatsächlich durchführen, um sicherzustellen, dass Sie mit den Schritten vertraut sind.
• Erstellen Sie ein Runbook, um die Schritte während der Übung zu dokumentieren. Auf dieses können Sie während der tatsächlichen Migration zurückgreifen.

Das Runbook könnte außerdem Folgendes enthalten:

• Smoke Tests: Nach der Migration werden Testfälle ausgeführt, um den Erfolg zu bestätigen. (Ein Test zur Validierung, ob die Anwendung die erwarteten Daten enthält und ob sowohl die Datenbank als auch der Dateispeicher migriert wurden und synchronisiert sind.)
• Schritte zum Aktualisieren von DNS-Einträgen und Lastenausgleichsmodulen, um Benutzer zur neuen Zielumgebung umzuleiten.
• Ein Plan für den schlimmsten Fall, falls die Migration fehlschlägt oder das zugewiesene Migrationsfenster abläuft.
• Kommunikation mit Benutzern, Beteiligten usw. im Falle verschiedener Szenarien.

Migration

As Mendix unterstützt eine breite Palette von Datenbank-, Dateispeicher- und Bereitstellungstypen gibt es ebenso mehrere Ansätze zur Migration. Ich werde den vielseitigsten Migrationsansatz mit benutzerdefinierten Laufzeiteinstellungen demonstrieren.

In diesem Beispiel werde ich eine App migrieren, die auf Mendix Cloud zu meiner neuen selbstgehosteten Umgebung, die im Azure Kubernetes Service (AKS) ausgeführt wird. Darin werden eine Azure SQL-Datenbank und Azure Blob Storage zur Dateispeicherung ausgeführt.

A Mendix Die Migration erfordert zwei Teile: zuerst die Migration der Datenbank und dann zweitens des Dateispeichers.

Benutzerdefinierte Laufzeiteinstellungen

Der Mendix Runtime verfügt über integrierte Migrationsfunktionen über Benutzerdefinierte Laufzeiteinstellungen. Diese Einstellungen übertragen Daten von einer Quell- in eine Zieldatenbank. Dabei wird auch die Datenbank konvertiert. Wenn also die Quelldatenbank PostgresSQL und unser Ziel MSSQL ist, übernimmt die Laufzeit dies für uns.

Die am häufigsten verwendeten benutzerdefinierten Einstellungen für die Datenbankmigration sind:

• Quelldatenbanktyp (HSQLDB, MYSQL, ORACLE, POSTGRESQL, SQLSERVER)
• Quelldatenbankhost
• Quelldatenbankname
• Quelldatenbankbenutzername
• Quelldatenbankkennwort

Unsere neue Zielumgebung läuft in Azure. Wir müssen also nur die benutzerdefinierten Laufzeiteinstellungen wie oben konfigurieren und auf unsere Quelldatenbank in der Mx Cloud verweisen, richtig?

Ja, aber die Mendix Die Cloud erlaubt keinen direkten Datenbankzugriff.

Daher müssen wir unsere eigene, temporäre PostgresSQL-Datenbank erstellen, das Mx Cloud-Backup darauf wiederherstellen und dann diese temporäre Datenbank als unsere Quelle in den benutzerdefinierten Laufzeiteinstellungen verwenden.

Wenn Ihre Zieldatenbank ebenfalls PostGresSQL ist, sind keine Konvertierung, keine benutzerdefinierten Laufzeiteinstellungen und keine temporäre Datenbank erforderlich. Stellen Sie einfach die Mendix Cloud-Backup direkt in Ihre Zieldatenbank mit PostgreSQL-Wiederherstellungsfunktionen.

Überprüfen Sie, ob die Zieldatenbank und der Dateispeicher leer sind.

Der Zieldateispeicher und die Zieldatenbank müssen vor der Durchführung einer Migration leer sein.

Vielleicht haben Sie Ihr Ziel begonnen Mendix Anwendung, Tests zur Bestätigung ihrer Funktionsfähigkeit ausgeführt und dabei unbeabsichtigt Daten erstellt. Diese müssen vor der Migration entfernt werden.

Azure Blog Storage (Ziel)

Azure SQL Server (Ziel)

Meine Zieldatenbank ist nicht leer. Sie enthält die Anwendungstabellen, die gelöscht werden müssen, damit die Migration funktioniert.

Ich schrieb eine kurze Excel-Funktion um die notwendigen SQL-Befehle zum Löschen aller Tabellen zu schreiben, ohne den Browser zu verlassen.

Eine Alternative hätte sein können SQL Server Management Studio (SSMS) das über eine visuelle GUI zum Löschen von Tabellen mit wenigen Klicks verfügt.

Nachdem ich diese Befehle ausgeführt habe, ist meine Datenbank leer.

Machen Sie den Schnappschuss 📸

Es ist Zeit, die letzte Sicherung unserer Produktionsdaten zu erstellen und mit der Migration zu beginnen. Mendix Da die Cloud ein Self-Service-Dienst ist, ist dies ganz einfach umzusetzen.

Von dem Mendix Cloud-Entwicklerportal:

1. Backups > Produktion > Backup erstellen (Mendix erstellt einen Snapshot Ihrer Daten)
2. Backup herunterladen > Vollständiger Snapshot (Je nach Größe Ihrer Anwendung kann dies einige Minuten bis mehrere Stunden dauern.)

Ein vollständiger Snapshot enthält ein komprimiertes *.tar.gz-Archiv, das unter Windows mit 7-Zip extrahiert werden kann.

Die Ordnerstruktur ist wie folgt:

• db – Das Postgres-Datenbank-Backup
• tree – Der Dateispeicher

Die temporäre PostgresSQL-Datenbank

Erstellen Sie eine PostgresSQL-Datenbank. Dies ist eine temporäre Lösung, um eine Datenbank zu erhalten, die wir kontrollieren und zu der wir die Verbindungsdetails haben.

Da sich meine Zielumgebung in Azure befindet, werde ich einen Azure Postgres-Datenbankserver erstellen.

Hinweis: Um die Daten zu migrieren, benötigt die Zielumgebung eine Netzwerkverbindung zur temporären Datenbank.

Stellen Sie sicher, dass die temporäre PostGresSQL-Datenbank dieselbe Version hat wie Ihre Quelldatenbank (zu finden auf der Seite mit den Umgebungsdetails des Mx-Entwicklerportals).

Um die Wiederherstellung durchzuführen, müssen wir mit unserer neu erstellten temporären Datenbank interagieren können. Ich werde pgAdmin 4 installieren, da dies eine einfache GUI-Schnittstelle bietet:

Laden Sie Postgres herunter und installieren Sie es auf Ihrem lokalen Computer.

(PostgreSQL: Downloads) Stellen Sie sicher, dass pgAdmin und PostgreSQL Server ausgewählt sind (erforderlich für die Wiederherstellungsfunktion).

Legen Sie beim ersten Start von pgAdmin ein Master-Passwort fest

Stellen Sie eine Verbindung zu unserem Azure PostgresSQL-Server her, indem Sie die Verbindungsdetails verwenden

Erstellen einer temporären Datenbank

Stellen Sie die Sicherung wieder her

Die Wiederherstellung zu PostGresSQL ist unkompliziert.
Wählen Sie einfach Ihre Sicherungsdatei „db.backup“ aus und stellen Sie sicher, dass „Besitzer nicht speichern“ auf „true“ eingestellt ist.
Weitere Details finden Sie hier.

Überprüfen der temporären Datenbankwiederherstellung

Unsere Daten sind da, die Wiederherstellung in unsere temporäre Datenbank war erfolgreich.

Wir haben jetzt unsere Produktionsdaten in einer von uns kontrollierten Datenbank und verfügen über die Verbindungsdaten!

Migrieren der Datenbank

Migrationen von Postgres zu Postgres sind daher extrem einfach. Wenn Ihre Zieldatenbank PostgresSQL ist, können Sie die oben genannten Schritte einfach direkt in Ihrer Zieldatenbank ausführen..

Ich muss eine Konvertierung und Migration zu MS SQL Server (Azure SQL) durchführen. Glücklicherweise können wir dies über benutzerdefinierte Laufzeiteinstellungen tun.

Stellen Sie sicher, dass die Zielanwendung gestoppt wurde

Festlegen der benutzerdefinierten Laufzeitvariablen

Starten Sie die Zielumgebung und überprüfen Sie, ob die Datenbankwiederherstellung funktioniert hat.

Die Daten wurden erfolgreich migriert.

Aber warten Sie, die Dateidokumente werden zwar angezeigt, aber nicht heruntergeladen. Das liegt daran, dass wir die Datenbank, die die Metadaten enthält, wiederhergestellt haben, den Dateispeicher aber noch nicht migriert haben.

Migrieren des Dateispeichers

Dies ist die einfachste der beiden Migrationen. Wir müssen lediglich die Dateien in unserem Snapshot in den Zieldateispeicher hochladen, in meinem Fall Azure Blob Storage.

Ordnerstruktur reduzieren (falls erforderlich)

Die Azure Blob Storage-Unterstützung in Mendix erwartet, dass alle Objekte in einem Ordner verfügbar sind. Daher muss ich alle Dateien in einem Stammverzeichnis ablegen und speichern. Da ich ein Windows-Benutzer bin, verwende ich ein einfaches PowerShell-Skript um dies zu tun.

Get-ChildItem -Path SOURCE -Recurse -File | Move-Item -Destination DEST

Hochladen von Dateien in den Azure Blob Storage-Container

Für größere Migrationen mit Tausenden von Dateien mit einer Größe von über 100 GB bevorzugen Sie möglicherweise Azure-CLI or Azure Storage-Explorer.

In meinem Szenario habe ich nur zwei Dateien, deshalb verwende ich das Azure-Webportal.

Rauchtest
Wenn ich die Anwendung erneut ausführe, habe ich jetzt vollen Zugriff auf meine Daten und Dateiinhalte!

Die Datenmigration war erfolgreich.

Einpacken

Beim Umgang mit echten Produktionsdaten ist es wichtig, nach der Migration eine Bereinigungsaktivität auszuführen, um sicherzustellen, dass diese Daten sicher bleiben. Dies könnte Folgendes umfassen:

• Löschen lokaler Downloads von Produktionssicherungen
• Zerstören aller temporären Datenbanken
• Entfernen der benutzerdefinierten Laufzeiteinstellungen in der Zielumgebung

Schlussworte

Es gibt so viele mögliche Migrationskombinationen, Setups und Infrastrukturdesigns, dass ich sie unmöglich alle in einem einzigen Beitrag abdecken kann. Ich habe speziell ein komplexes Szenario behandelt, das Sie mit denselben Techniken an Ihr eigenes Datenmigrationsszenario anpassen können.

Alternative Ansätze

• Migration zwischen Mx4PC zu Mx4PC oder Mendix Cloud zu Mx4PC mit einer PG-Datenbank? Nutzen Sie die neue Tool zur Datenmigration in die private Cloud (zum Zeitpunkt des Schreibens derzeit in der Vorschau).
• Benötigen Sie einen Bastion-Host, können Sie eine Windows-VM mit einer lokalen Installation von Postgres einrichten und die Mendix Servicekonsole um die Datenbank auf Ihr Ziel zu migrieren.

Migrieren Sie es!