Spielt mal ein wenig in Azure rum, haben sie gesagt. Und am Ende war das Chaos.

Fängt man an sich in der Welt der Cloud zu bewegen kommt man automatisch in Versuchung, schnell Dinge auszuprobieren. Doch ehe man es sich versieht hat man erste produktive Services im Betrieb und kriegt das Chaos kaum noch in den Griff. Aus dem Grund folgt nun eine Reihe von Beiträgen mit unseren Erfahrungen. In diesem Fall geht es um die Azure Cloud von Microsoft. In unseren Beiträgen setzen wir voraus, dass ihr mit der Azure CLI umgehen könnt.

Da wir in der Vergangenheit keine guten Erfahrungen gemacht haben was Azure-Internes rumgeschiebe von Ressourcen anbelangt bin ich mit etwas Sorge an den Versuch gegangen, eine Azure PostgreSQL Database von einer in eine andere Azure Subscription zu migrieren.

Allerdings stellte sich die Sorge schnell unbegründet heraus. Zumindest in einem einfachen Test hat der Subscription-Wechsel mit lediglich einer Downtime von etwa fünf Minuten gut funktioniert.

Zunächst sucht euch die richtige Datenbank raus:

az postgres server list

Um auf Nummer sicher zu gehen legt ein Backup an. Dafür benötigt ihr die Befehlszeilenprogramme pg_dump und pg_restore.

Mit folgenden Befehlen könnt ihr euch einen Dump ziehen und ihn in einer anderen PostgreSQL-Datenbank wieder einspielen:

pg_dump -h <MySourceServerName.postgres.database.azure.com> -U <MySourceUserName> -Fc -d <MySourceDatabaseName> -f /your/folder/MyDatabaseBackup.dump
pg_restore -h <MyTargetServer.postgres.database.azure.com> -U <MyAzurePostgreSQLUserName> -Fc -j 4 -d <MyTargetDatabase> /your/folder/MyDatabaseBackup.dump

Anschließend trauen wir uns über das Azure Portal den Umzug in eine neue Subscription.

Einfach eure Datenbank auswählen und unter „Subscription“ auf „Change“ klicken:

Im Anschluss werden die assoziierten Ressourcen angezeigt, welche ihr ebenfalls migrieren könnt – aber nicht müsst.

Beachtet aber, dass sich die Ressource ID der Datenbank ändert. Sollte diese irgendwo referenziert sein wird die Assoziation nach dem Wechsel der Subscription nicht mehr funktionieren.

Wenn keine Fehler bei der Validierung auftreten (die etwa 2-3 Minuten dauert) wird die Migration gestartet.

Je nach Größe der Datenbank kommt es anschließend zu einer Downtime – bei mir im Test mit einer einzigen Tabelle war die Downtime 4-5 Minuten. Sobald wir Erfahrungswerte mit größeren Datenbanken haben aktualisieren wir diesen Artikel.

Und das war es auch schon.

Wenn ihr Azure an dieser Stelle nicht vertraut könnt ihr auch einfach eine neue PostgreSQL Database anlegen und die Daten wie oben beschrieben sichern und wieder einspielen. Dann habt ihr aber sicher eine längere Downtime, da ihr ja dann auch die Referenzierungen in euren Applikationen anpassen müsst.

Have fun 🙂