Tutorial: Migrieren von Azure Database for PostgreSQL – Single Server zu Azure Database for PostgreSQL – Flexibler Server mit dem Migrationsdienst

GILT FÜR: Azure Database for PostgreSQL – Flexible Server

Sie können mithilfe des Azure-Portals eine Instanz von Azure Database for PostgreSQL – Single Server zu Azure Database for PostgreSQL – Flexibler Server migrieren. In diesem Tutorial führen wir mithilfe des Azure-Portals die Migration einer Beispieldatenbank von einem Azure Database for PostgreSQL -Einzelserver zu einem flexiblen Azure Database for PostgreSQL-Server durch.

• Konfigurieren Ihrer Instanz des flexiblen Azure Database for PostgreSQL-Servers
• Konfigurieren der Migrationsaufgabe
• Überwachen der Migration
• Abbrechen der Migration
• Nach der Migration

Portal

Sie können die Migration über das Azure-Portal durchführen.

Offline

Voraussetzungen (Offline)

Bevor Sie Ihre Migration mit dem Migrationsdienst in Azure Database for PostgreSQL starten, müssen Sie unbedingt die folgenden Voraussetzungen erfüllen, die für Offlinemigrationsszenarien gelten.

Überprüfen der Quellversion

Die PostgreSQL-Quellversion sollte >= 9.5 sein. Wenn die PostgreSQL-Quellversion kleiner als 9.5 ist, aktualisieren Sie die PostgreSQL-Quellversion auf 9.5 oder höher, bevor Sie migrieren.

Zielsetup

• Azure Database for PostgreSQL muss vor der Migration in Azure eingerichtet werden.

• Die für die Azure Database for PostgreSQL-Instanz gewählte SKU sollte den Spezifikationen der Quelldatenbank entsprechen, um Kompatibilität und angemessene Leistung sicherzustellen.

• Ausführliche Anweisungen zum Erstellen einer neuen Azure Database for PostgreSQL-Instanz finden Sie unter dem folgenden Link: Schnellstart: Erstellen eines Servers.

Netzwerkeinrichtung

Das ordnungsgemäße Netzwerksetup ist unerlässlich, um während der Migration eine erfolgreiche Verbindung zwischen der Quelle und dem Ziel sicherzustellen. Im Folgenden finden Sie eine Anleitung zum Einrichten der Netzwerkverbindung für verschiedene Szenarien:

Netzwerkanforderungen für die Migration:

• ExpressRoute-/IPsec-VPN-/VPN-Tunneling: Wenn Sie Ihre lokale/AWS-Quelle mit Azure verbinden, müssen Sie möglicherweise eine ExpressRoute, ein IPsec-VPN oder VPN-Tunneling einrichten, um eine sichere Datenübertragung zu ermöglichen.

• VNet-Peering: Richten Sie Peering virtueller Netzwerke zwischen den beiden unterschiedlichen VNets ein, um die direkte Netzwerkkonnektivität zu ermöglichen, eine Voraussetzung für die Migration zwischen der Azure-VM und der Azure Database for PostgreSQL-Instanz.

Konnektivitätsszenarien:

Die folgende Tabelle kann beim Einrichten des Netzwerks zwischen der Quelle und dem Ziel helfen.

Quelle	Ziel	Konnektivitätstipps
Öffentlich	Öffentlich	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Public	Diese Konfiguration wird nicht unterstützt. Verwenden Sie pg_dump/pg_restore für die Datenübertragung.
Öffentlich	Privat	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Privat	Richten Sie eine ExpressRoute, ein IPsec-VPN, VPN-Tunneling oder Peering virtueller Netzwerke zwischen der Quelle und dem Ziel ein.
Privat	Privater Endpunkt	Diese Konfiguration wird nicht unterstützt. Wenden Sie sich an den Microsoft-Support.

Zusätzliche Überlegungen zum Netzwerk:

• pg_hba.conf-Konfiguration: Um die Konnektivität zwischen den PostgreSQL-Quell- und Zielinstanzen zu unterstützen, ist es wichtig, die Datei pg_hba.conf zu überprüfen und gegebenenfalls zu ändern. Diese Datei enthält die Clientauthentifizierung und muss so konfiguriert sein, dass die PostgreSQL-Zielinstanz eine Verbindung mit der Quelle herstellen kann. Änderungen an der Datei pg_hba.conf erfordern in der Regel einen Neustart der PostgreSQL-Quellinstanz, um wirksam zu werden.

Hinweis

Die Datei pg_hba.conf befindet sich im Datenverzeichnis der PostgreSQL-Installation. Diese Datei sollte überprüft und konfiguriert werden, wenn es sich bei der Quelldatenbank um einen lokalen PostgreSQL-Server handelt, oder einen PostgreSQL-Server, der auf einer Azure-VM gehostet wird. Bei PostgreSQL-Instanzen auf AWS RDS oder ähnlichen verwalteten Diensten ist die Datei pg_hba.conf nicht direkt zugänglich oder anwendbar. Stattdessen wird der Zugriff über die bereitgestellten Sicherheits- und Netzwerkzugriffskonfigurationen des Diensts gesteuert.

Weitere Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst in Azure Database for PostgreSQL – Flexibler Server.

Erweiterungen

Erweiterungen sind zusätzliche Features, die PostgreSQL hinzugefügt werden können, um seine Funktionalität zu verbessern. Erweiterungen werden in Azure Database for PostgreSQL unterstützt, müssen jedoch manuell aktiviert werden. Führen Sie die folgenden Schritte aus, um Erweiterungen zu aktivieren:

• Verwenden Sie den Befehl „auswählen“ in der Quelle, um alle Erweiterungen aufzulisten, die verwendet werden – select extname,extversion from pg_extension;

• Suchen Sie auf der Seite „Serverparameter“ in Ihrer Azure Database for PostgreSQL-Instanz nach dem Serverparameter azure.extensions. Aktivieren Sie die Erweiterungen, die in der Quelle in PostgreSQL gefunden wurden.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

  

• Überprüfen Sie, ob die Liste eine der folgenden Erweiterungen enthält:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Wenn ja, durchsuchen Sie die Seite „Serverparameter“ nach dem Parameter shared_preload_libraries. Dieser Parameter gibt den Satz von Erweiterungsbibliotheken an, der beim Neustart des Servers vorab geladen wird.

Serverparameter

Diese Parameter werden nicht automatisch in die Zielumgebung migriert und müssen manuell konfiguriert werden.

• Stimmen Sie Serverparameterwerte aus der PostgreSQL-Quelldatenbank mit der Azure Database for PostgreSQL-Instanz ab, indem Sie im Azure-Portal auf den Abschnitt „Serverparameter“ zugreifen und die Werte entsprechend manuell aktualisieren.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und Lesereplikaten im Ziel

• Das Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und der Lesereplikate in der Zielumgebung ist unerlässlich. Diese Features sollten erst aktiviert werden, nachdem die Migration abgeschlossen wurde.

• Wenn Sie diese Richtlinien befolgen, können Sie einen reibungslosen Migrationsprozess ohne die zusätzlichen Variablen sicherstellen, die durch Hochverfügbarkeit und Lesereplikate eingeführt wurden. Sobald die Migration abgeschlossen und die Datenbank stabil ist, können Sie diese Features aktivieren, um die Verfügbarkeit und Skalierbarkeit Ihrer Datenbankumgebung in Azure zu verbessern.

Konfigurieren Ihrer Instanz des flexiblen Azure Database for PostgreSQL-Servers

• Erstellen Sie den flexiblen Zielserver. Eine Anleitung finden Sie in der Schnellstartanleitung Erstellen eines flexiblen Azure Database for PostgreSQL-Servers über das Portal.

• Erweiterungen der Positivliste, deren Bibliotheken beim Serverstart geladen werden müssen. Es ist wichtig, dass sich die Erweiterung auf der Positivliste befindet, bevor Sie eine Migration initiieren.

• Prüfen Sie, ob die Datenverteilung auf alle Datenbanktabellen geneigt ist, wobei die meisten Daten in einer einzigen (oder in wenigen) Tabellen vorhanden sind. Wenn sie geneigt ist, kann die Migrationsgeschwindigkeit langsamer als erwartet sein. In diesem Fall kann die Migrationsgeschwindigkeit erhöht werden, indem Sie die große Tabelle parallel migrieren.

Konfigurieren der Migrationsaufgabe

Der Migrationsdienst verfügt über eine einfache, Assistenten-basierte Erfahrung im Azure-Portal. Gehen Sie wie folgt vor:

1. Browsen Sie zum Portal. Geben Sie zum Anmelden Ihre Anmeldeinformationen ein. Die Standardansicht ist Ihr Dienstdashboard.

2. Navigieren Sie zu Ihrer Zielinstanz von Azure Database for PostgreSQL – Flexible Server.

3. Scrollen Sie auf der Registerkarte Übersicht für die Flexible Server-Instanz im linken Menü nach unten zu Migration, und wählen Sie diese Option aus.

   

4. Wählen Sie die Schaltfläche Erstellen aus, um eine Migration von Single Server zu Flexibler Server zu starten. Wenn Sie den Migrationsdienst zum ersten Mal verwenden, erscheint ein leeres Raster mit einer Eingabeaufforderung, um mit Ihrer ersten Migration zu beginnen.

   

   Wenn Sie bereits Migrationen zu Ihrem Ziel für den flexiblen Server erstellt haben, enthält das Raster Informationen zu versuchten Migrationen vom Einzelserver zu diesem Ziel.

5. Wählen Sie die Schaltfläche Von einzelnem Server migrieren aus. Sie durchlaufen mehrere assistentenbasierte Registerkarten, um eine Migration von einer Einzelserverquelle zu diesem Ziel für den flexiblen Server zu erstellen.

Alternativ können Sie den Migrationsprozess aus dem Azure Database for PostgreSQL Single Server initiieren.

1. Browsen Sie zum Portal. Zum Anmelden müssen Sie Ihre Anmeldeinformationen eingeben. Die Standardansicht ist Ihr Dienstdashboard.

2. Wenn Sie den Einzelserver auswählen, können Sie auf der Registerkarte „Übersicht“ ein Banner sehen, das sich auf die Migration bezieht. Wählen Sie Jetzt migrieren aus, um zu beginnen.

   

3. Sie gelangen auf eine Seite mit zwei Optionen. Wenn Sie bereits einen flexiblen Server erstellt haben und diesen als Ziel verwenden möchten, wählen Sie Vorhandenes auswählen aus, und wählen Sie dann die entsprechenden Details für Abonnement, Ressourcengruppe und Servername aus. Nachdem die Auswahl getroffen wurde, wählen Sie Zum Migrations-Assistenten wechseln aus, und fahren Sie mit den Anweisungen unter dem Abschnitt Einrichten auf dieser Seite fort.

   

4. Wenn Sie einen neuen flexiblen Server erstellen möchten, wählen Sie Neu erstellen aus, und wählen Sie dann Zum Erstellungs-Assistenten wechseln aus. Diese Aktion führt Sie durch den Erstellungsprozess für flexible Server und stellt den flexiblen Server bereit.

   

Führen Sie nach der Bereitstellung des flexiblen Servers die Schritte 3 bis 5 unter Konfigurieren des Migrationstasks aus.

Registerkarte „Setup“

Die erste Registerkarte ist Einrichtung. Falls Sie es übersehen haben, lassen Sie die notwendigen Erweiterungen zu, wie in „Es ist wichtig, diese Erweiterungen zuzulassen, bevor Sie eine Migration starten“ beschrieben.

Beim Migrationsnamen handelt es sich um den eindeutigen Bezeichner für eine Migration zu diesem Flexible Server-Ziel. In dieses Feld dürfen nur alphanumerische Zeichen eingegeben werden, und mit Ausnahme von Bindestrichen (-) dürfen keine Sonderzeichen verwendet werden. Der Name darf nicht mit einem Bindestrich beginnen und muss für den Zielserver eindeutig sein. Zwei Migrationen zum selben Flexible Server-Ziel dürfen nicht denselben Namen aufweisen.

Der Quellservertyp gibt die Quelle an. In diesem Fall handelt es sich um Azure Database for PostgreSQL – Single Server.

Migrationsoption – Ermöglicht es Ihnen, Validierungen durchzuführen, bevor Sie eine Migration auslösen. Sie können eine der folgenden Optionen auswählen.

• Überprüfen: Mit dieser Option werden die Server- und Datenbankbereitschaft für die Migration zum Ziel überprüft.
• Migrieren: Überspringt Überprüfungen und startet die Migration.
• Überprüfen und migrieren: Führt eine Überprüfung durch, bevor eine Migration ausgelöst wird. Die Migration wird nur ausgelöst, wenn keine Überprüfungsfehler auftreten.

Es empfiehlt sich immer, die Option Überprüfen oder Überprüfen und migrieren auszuwählen, um vor dem Ausführen der Migration Überprüfungen durchzuführen.

Wenn die Vorschau für die Onlinemigrationen ausgewählt ist, muss die logische Replikation auf dem Single-Quellserver aktiviert sein. Wenn sie nicht aktiviert ist, aktiviert der Migrationsdienst automatisch die logische Replikation auf dem Quellserver. Replikation kann auch manuell auf der Registerkarte Replikation im Bereich „Single Server“ eingerichtet werden, indem die Azure-Replikationsunterstützungsebene auf Logisch festgelegt wird. Bei beiden Ansätzen wird der Quellserver neu gestartet.

Wählen Sie die Schaltfläche Weiter : Mit Quelle verbinden aus.

Registerkarte „Quelle“

Auf der Registerkarte Quelle werden Sie aufgefordert, Details zur Single-Serverquelle anzugeben, die die Quelle der Datenbanken ist.

Nachdem Sie eine Auswahl für Abonnement und Ressourcengruppe vorgenommen haben, werden in der Dropdownliste für Servernamen Single Server-Quellen in dieser Ressourcengruppe in den verschiedenen Regionen angezeigt. Wählen Sie die Quelle aus, von der Datenbanken migriert werden sollen. Beachten Sie, dass Sie Datenbanken von einem Einzelserver zu einem flexiblen Zielserver in derselben Region migrieren können. Regionsübergreifende Migrationen sind lediglich für Server in Indien, China und VAE aktiviert.

Nach Auswahl der Einzelserverquelle werden die Felder für Standort, PostgreSQL-Version und Anmeldename des Serveradministrators automatisch ausgefüllt. Beim Anmeldenamen des Serveradmin handelt es sich um den Benutzernamen des Admin, der zum Erstellen des Einzelservers verwendet wurde. Geben Sie im Feld Kennwort das Kennwort für den betreffenden Administratorbenutzer ein. Der Migrationsdienst führt die Migration von Single Server-Datenbanken als Administratorbenutzer aus.

Wählen Sie nach dem Ausfüllen aller Felder den Link Mit Quelle verbinden aus. Dadurch wird überprüft, ob die eingegebenen Quellserverdetails korrekt sind und der Quellserver erreichbar ist.

Wählen Sie die Schaltfläche Weiter : Migrationsziel auswählen aus, um fortzufahren.

Registerkarte „Ziel“

Auf der Registerkarte Ziel werden Metadaten für das Flexibler Server-Ziel angezeigt, z. B. Abonnementname, Ressourcengruppe, Servername, Speicherort und PostgreSQL-Version.

Als Anmeldename des Serveradmin zeigt die Registerkarte den Administratornamen an, der bei der Erstellung des Flexibler Server-Ziels verwendet wurde. Geben Sie das entsprechende Kennwort für den Administratorbenutzer ein. Wählen Sie nach dem Ausfüllen des Kennworts den Link Mit Ziel verbinden aus. Dadurch wird überprüft, ob die eingegebenen Zielserverdetails korrekt sind und der Zielserver erreichbar ist.

Wählen Sie die Schaltfläche Weiter aus, um die zu migrierenden Datenbanken auszuwählen.

Auswählen von Datenbanken für dien Registerkarte „Migration“

In dieser Registerkarte befindet sich eine Liste der Benutzerdatenbanken auf dem Einzelserver. Sie können bis zu acht Datenbanken im Rahmen eines einzelnen Migrationsversuchs auswählen und migrieren. Wenn mehr als acht Benutzerdatenbanken vorhanden sind, wird der Migrationsprozess zwischen den Quell- und Zielservern für den nächsten Satz von Datenbanken wiederholt. Standardmäßig werden ausgewählte Datenbanken mit demselben Namen auf dem Ziel überschrieben.

Wählen Sie die Schaltfläche Weiter aus, um die Details zu überprüfen.

Zusammenfassung

Auf der Registerkarte Zusammenfassung wird eine Zusammenfassung aller Details zum Erstellen der Validierung oder Migration angezeigt. Überprüfen Sie die Details, und wählen Sie die Schaltfläche „Starten“ aus.

Überwachen des Migrationsportals

Nach Auswahl der Schaltfläche „Starten“ wird nach einigen Sekunden eine Benachrichtigung angezeigt, die Sie informiert, dass die Überprüfungs- oder Migrationserstellung erfolgreich war. Sie werden automatisch zur Seite Migration für Flexibler Server umgeleitet. Dieses Blatt weist einen neuen Eintrag für die kürzlich erstellte Überprüfung oder Migration auf.

Das Raster, in dem die Migrationen angezeigt werden, enthält folgende Spalten: Name, Status, Migrationstyp, Migrationsmodus, Quellserver, Quellservertyp, Datenbanken, Startzeit und Dauer. Die Einträge werden in absteigender Reihenfolge nach Startzeit (letzter Eintrag zuerst) angezeigt.

Sie können die Schaltfläche zum Aktualisieren verwenden, um den Status der Überprüfung oder Migration zu aktualisieren. Sie können auch den Migrationsnamen im Raster auswählen, um zugehörige Details anzuzeigen.

Nach dem Erstellen der Überprüfung oder Migration wird diese in den Zustand InProgress und in den Unterzustand PerformingPreRequisiteSteps versetzt. Der Workflow benötigt 2 bis 3 Minuten, um die Migrationsinfrastruktur und die Netzwerkverbindungen einzurichten.

Sehen wir uns an, wie Migrationen für die einzelnen Migrationsoptionen überwacht werden.

Überprüfen

Nach Abschluss des Unterzustands PerformingPreRequisiteSteps wechselt die Überprüfung in den Unterzustand Überprüfung wird ausgeführt. In diesem Zustand werden Überprüfungen für den Quell- und den Zielserver ausgeführt, um die Bereitschaft für die Migration zu bewerten.

Die Überprüfung wechselt in den Zustand Erfolgreich, wenn alle Überprüfungen entweder den Status Erfolgreich oder den Status Warnung haben.

Das Validierungsraster enthält die

• Die Abschnitte Validierungsdetails für die Instanz und Validierungsdetails für Datenbanken, stellen die Validierungsregeln dar, mit denen die Bereitschaft für die Migration überprüft wird.
• Validierungsstatus – Stellt das Ergebnis für die einzelnen Regeln dar und kann einen der drei Werte haben
  • Erfolgreich, wenn keine Fehler gefunden wurden
  • Fehler, wenn Überprüfungsfehler vorliegen
  • Warnung, wenn Überprüfungswarnungen vorliegen
• Dauer – Zeitaufwand für den Validierungsvorgang.
• Start- und Endzeit – Start- und Endzeit des Validierungsvorgangs in UTC.

Der Validierungsstatus wechselt in den Status Fehlgeschlagen, wenn Fehler bei der Validierung auftreten. Wählen Sie den Validierungsnamen oder die Validierung des Datenbanknamens aus, der fehlgeschlagen ist. Ein Aufklappfenster enthält die Details und die Korrekturmaßnahmen, die Sie ergreifen sollten, um diesen Fehler zu vermeiden.

Migrieren

Nachdem der Unterzustand PerformingPreRequisiteSteps abgeschlossen wurde, wechselt die Migration in den Unterzustand MigratingData, in dem die Datenbanken geklont bzw. kopiert werden. Die Dauer bis zum Anschluss der Migration hängt von der Größe und Form der Datenbanken ab, die Sie migrieren. Wenn die Daten weitgehend gleichmäßig über alle Tabellen verteilt sind, erfolgt die Migration schnell. Ungleiche Tabellengrößen benötigen eine relativ längere Zeit.

Wenn Sie eine beliebige Datenbank in einer Migration auswählen, wird ein Erweiterungsbereich angezeigt. Er verfügt über die gesamte Tabellenanzahl: kopiert, in die Warteschlange eingereiht, wird aktuell kopiert und Fehler, abgesehen vom Datenbankmigrationsstatus.

Die Migration wird in den Zustand Erfolgreich versetzt, wenn der Zustand MigratingData erfolgreich abgeschlossen wurde. Wenn beim Zustand MigratingData ein Problem auftritt, wird die Migration in den Zustand Failed versetzt.

Sobald die Migration in den Status Erfolgreich aufweist, ist die Migration des Schemas und der Daten von Ihrem Einzelserver zu Ihrem Ziel für den flexiblen Server abgeschlossen. Sie können die Schaltfläche „Aktualisieren“ auf der Seite verwenden, um dies zu bestätigen.

Überprüfen und migrieren

Bei dieser Option werden zuerst Überprüfungen vor Beginn der Migration ausgeführt. Nach Abschluss des Unterzustands PerformingPreRequisiteSteps wechselt der Workflow in den Unterzustand Überprüfung wird ausgeführt.

• Wenn bei der Überprüfung Fehler auftreten, wechselt die Migration in den Zustand Fehler.
• Wenn die Validierung ohne Fehler abgeschlossen ist, wird die Migration gestartet, und der Workflow wechselt in den Substatus Migrieren von Daten.

Sie können die Ergebnisse für Überprüfen und Migrieren sehen, sobald der Vorgang abgeschlossen ist.

Online (Vorschau)

Voraussetzungen (online)

Bevor Sie Ihre Migration mit dem Migrationsdienst in Azure Database for PostgreSQL starten, müssen Sie unbedingt die folgenden Voraussetzungen erfüllen, die für Offlinemigrationsszenarien gelten.

Überprüfen der Quellversion

Die PostgreSQL-Quellversion sollte >= 9.5 sein. Wenn die PostgreSQL-Quellversion kleiner als 9.5 ist, aktualisieren Sie die PostgreSQL-Quellversion auf 9.5 oder höher, bevor Sie migrieren.

Einrichten von Parametern für die Onlinemigration

Für die Onlinemigration sollte die Replikationsunterstützung unter „Replikationseinstellungen“ in der Quelle „PostgreSQL-Server“ eingestellt werden. Darüber hinaus sollten die Werte der Serverparameter max_wal_senders und max_replication_slots größer sein als die Anzahl der zu migrierenden Datenbanken. Die Parameter können im Azure-Portal unter Einstellungen>Serverparameter festgelegt oder in der Befehlszeile mit den folgenden Befehlen konfiguriert werden:

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Stellen Sie sicher, dass keine zeitintensive Transaktionen vorhanden sind. Zeitintensive Transaktionen lassen die Erstellung von Replikationsplätzen nicht zu. Die Erstellung eines Replikationsslots ist erfolgreich, wenn alle lang laufenden Transaktionen bestätigt oder zurückgenommen wurden. Sie müssen den PostgreSQL-Quellserver neu starten, nachdem alle Voraussetzungen für die Onlinemigration erfüllt sind.

Hinweis

Für die Onlinemigration mit Azure Database for PostgreSQL – Single Server ist die Azure-Replikationsunterstützung unter den Replikationseinstellungen auf der Seite „Single Server“ im Azure-Portal auf „Logisch“ eingestellt.

Zielsetup

• Azure Database for PostgreSQL muss vor der Migration in Azure eingerichtet werden.

• Die für die Azure Database for PostgreSQL-Instanz gewählte SKU sollte den Spezifikationen der Quelldatenbank entsprechen, um Kompatibilität und angemessene Leistung sicherzustellen.

• Ausführliche Anweisungen zum Erstellen einer neuen Azure Database for PostgreSQL-Instanz finden Sie unter dem folgenden Link: Schnellstart: Erstellen eines Servers.

• Der Werts des Serverparameters max_replication_slots sollte größer sein als die Anzahl der zu migrierenden Datenbanken. Er kann im Azure-Portal unter Einstellungen>Serverparameter festgelegt oder in der Befehlszeile mit dem folgenden Befehl konfiguriert werden:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Netzwerkeinrichtung

Das ordnungsgemäße Netzwerksetup ist unerlässlich, um während der Migration eine erfolgreiche Verbindung zwischen der Quelle und dem Ziel sicherzustellen. Im Folgenden finden Sie eine Anleitung zum Einrichten der Netzwerkverbindung für verschiedene Szenarien:

Netzwerkanforderungen für die Migration:

• ExpressRoute-/IPsec-VPN-/VPN-Tunneling: Wenn Sie Ihre lokale/AWS-Quelle mit Azure verbinden, müssen Sie möglicherweise eine ExpressRoute, ein IPsec-VPN oder VPN-Tunneling einrichten, um eine sichere Datenübertragung zu ermöglichen.

• VNet-Peering: Richten Sie Peering virtueller Netzwerke zwischen den beiden unterschiedlichen VNets ein, um die direkte Netzwerkkonnektivität zu ermöglichen, eine Voraussetzung für die Migration zwischen der Azure-VM und der Azure Database for PostgreSQL-Instanz.

Konnektivitätsszenarien:

Die folgende Tabelle kann beim Einrichten des Netzwerks zwischen der Quelle und dem Ziel helfen.

Quelle	Ziel	Konnektivitätstipps
Öffentlich	Öffentlich	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Public	Diese Konfiguration wird nicht unterstützt. Verwenden Sie pg_dump/pg_restore für die Datenübertragung.
Öffentlich	Privat	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Privat	Richten Sie eine ExpressRoute, ein IPsec-VPN, VPN-Tunneling oder Peering virtueller Netzwerke zwischen der Quelle und dem Ziel ein.
Privat	Privater Endpunkt	Diese Konfiguration wird nicht unterstützt. Wenden Sie sich an den Microsoft-Support.

Weitere Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst in Azure Database for PostgreSQL – Flexibler Server.

Erweiterungen

Erweiterungen sind zusätzliche Features, die PostgreSQL hinzugefügt werden können, um seine Funktionalität zu verbessern. Erweiterungen werden in Azure Database for PostgreSQL unterstützt, müssen jedoch manuell aktiviert werden. Führen Sie die folgenden Schritte aus, um Erweiterungen zu aktivieren:

• Verwenden Sie den Befehl „auswählen“ in der Quelle, um alle Erweiterungen aufzulisten, die verwendet werden – select extname,extversion from pg_extension;

• Suchen Sie auf der Seite „Serverparameter“ in Ihrer Azure Database for PostgreSQL-Instanz nach dem Serverparameter azure.extensions. Aktivieren Sie die Erweiterungen, die in der Quelle in PostgreSQL gefunden wurden.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

  

• Überprüfen Sie, ob die Liste eine der folgenden Erweiterungen enthält:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Wenn ja, durchsuchen Sie die Seite „Serverparameter“ nach dem Parameter shared_preload_libraries. Dieser Parameter gibt den Satz von Erweiterungsbibliotheken an, der beim Neustart des Servers vorab geladen wird.

Serverparameter

Diese Parameter werden nicht automatisch in die Zielumgebung migriert und müssen manuell konfiguriert werden.

• Stimmen Sie Serverparameterwerte aus der PostgreSQL-Quelldatenbank mit der Azure Database for PostgreSQL-Instanz ab, indem Sie im Azure-Portal auf den Abschnitt „Serverparameter“ zugreifen und die Werte entsprechend manuell aktualisieren.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und Lesereplikaten im Ziel

• Das Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und der Lesereplikate in der Zielumgebung ist unerlässlich. Diese Features sollten erst aktiviert werden, nachdem die Migration abgeschlossen wurde.

• Wenn Sie diese Richtlinien befolgen, können Sie einen reibungslosen Migrationsprozess ohne die zusätzlichen Variablen sicherstellen, die durch Hochverfügbarkeit und Lesereplikate eingeführt wurden. Sobald die Migration abgeschlossen und die Datenbank stabil ist, können Sie diese Features aktivieren, um die Verfügbarkeit und Skalierbarkeit Ihrer Datenbankumgebung in Azure zu verbessern.

Konfigurieren Ihrer Instanz des flexiblen Azure Database for PostgreSQL-Servers

• Erstellen Sie den flexiblen Zielserver. Eine Anleitung finden Sie in der Schnellstartanleitung Erstellen eines flexiblen Azure Database for PostgreSQL-Servers über das Portal.

• Erweiterungen der Positivliste, deren Bibliotheken beim Serverstart geladen werden müssen. Es ist wichtig, dass sich die Erweiterung auf der Positivliste befindet, bevor Sie eine Migration initiieren.

• Prüfen Sie, ob die Datenverteilung auf alle Datenbanktabellen geneigt ist, wobei die meisten Daten in einer einzigen (oder in wenigen) Tabellen vorhanden sind. Wenn sie geneigt ist, kann die Migrationsgeschwindigkeit langsamer als erwartet sein. In diesem Fall kann die Migrationsgeschwindigkeit erhöht werden, indem Sie die große Tabelle parallel migrieren.

Konfigurieren der Migrationsaufgabe

Der Migrationsdienst verfügt über eine einfache, Assistenten-basierte Erfahrung im Azure-Portal. Gehen Sie wie folgt vor:

1. Browsen Sie zum Portal. Geben Sie zum Anmelden Ihre Anmeldeinformationen ein. Die Standardansicht ist Ihr Dienstdashboard.

2. Navigieren Sie zu Ihrer Zielinstanz von Azure Database for PostgreSQL – Flexible Server.

3. Scrollen Sie auf der Registerkarte Übersicht für die Flexible Server-Instanz im linken Menü nach unten zu Migration, und wählen Sie diese Option aus.

   

4. Wählen Sie die Schaltfläche Erstellen aus, um eine Migration von Single Server zu Flexibler Server zu starten. Wenn Sie den Migrationsdienst zum ersten Mal verwenden, erscheint ein leeres Raster mit einer Eingabeaufforderung, um mit Ihrer ersten Migration zu beginnen.

   

   Wenn Sie bereits Migrationen zu Ihrem Ziel für den flexiblen Server erstellt haben, enthält das Raster Informationen zu versuchten Migrationen vom Einzelserver zu diesem Ziel.

5. Wählen Sie die Schaltfläche Von einzelnem Server migrieren aus. Sie durchlaufen mehrere assistentenbasierte Registerkarten, um eine Migration von einer Einzelserverquelle zu diesem Ziel für den flexiblen Server zu erstellen.

Alternativ können Sie den Migrationsprozess aus dem Azure Database for PostgreSQL Single Server initiieren.

1. Browsen Sie zum Portal. Zum Anmelden müssen Sie Ihre Anmeldeinformationen eingeben. Die Standardansicht ist Ihr Dienstdashboard.

2. Wenn Sie den Einzelserver auswählen, können Sie auf der Registerkarte „Übersicht“ ein Banner sehen, das sich auf die Migration bezieht. Wählen Sie Jetzt migrieren aus, um zu beginnen.

   

3. Sie gelangen auf eine Seite mit zwei Optionen. Wenn Sie bereits einen flexiblen Server erstellt haben und diesen als Ziel verwenden möchten, wählen Sie Vorhandenes auswählen aus, und wählen Sie dann die entsprechenden Details für Abonnement, Ressourcengruppe und Servername aus. Nachdem die Auswahl getroffen wurde, wählen Sie Zum Migrations-Assistenten wechseln aus, und fahren Sie mit den Anweisungen unter dem Abschnitt Einrichten auf dieser Seite fort.

   

4. Wenn Sie einen neuen flexiblen Server erstellen möchten, wählen Sie Neu erstellen aus, und wählen Sie dann Zum Erstellungs-Assistenten wechseln aus. Diese Aktion führt Sie durch den Erstellungsprozess für flexible Server und stellt den flexiblen Server bereit.

   

Führen Sie nach der Bereitstellung des flexiblen Servers die Schritte 3 bis 5 unter Konfigurieren des Migrationstasks aus.

Registerkarte „Setup“

Die erste Registerkarte ist Einrichtung. Falls Sie es übersehen haben, lassen Sie die notwendigen Erweiterungen zu, wie in „Es ist wichtig, diese Erweiterungen zuzulassen, bevor Sie eine Migration starten“ beschrieben.

Beim Migrationsnamen handelt es sich um den eindeutigen Bezeichner für eine Migration zu diesem Flexible Server-Ziel. In dieses Feld dürfen nur alphanumerische Zeichen eingegeben werden, und mit Ausnahme von Bindestrichen (-) dürfen keine Sonderzeichen verwendet werden. Der Name darf nicht mit einem Bindestrich beginnen und muss für den Zielserver eindeutig sein. Zwei Migrationen zum selben Flexible Server-Ziel dürfen nicht denselben Namen aufweisen.

Der Quellservertyp gibt die Quelle an. In diesem Fall handelt es sich um Azure Database for PostgreSQL – Single Server.

Migrationsoption – Ermöglicht es Ihnen, Validierungen durchzuführen, bevor Sie eine Migration auslösen. Sie können eine der folgenden Optionen auswählen.

• Überprüfen: Mit dieser Option werden die Server- und Datenbankbereitschaft für die Migration zum Ziel überprüft.
• Migrieren: Überspringt Überprüfungen und startet die Migration.
• Überprüfen und migrieren: Führt eine Überprüfung durch, bevor eine Migration ausgelöst wird. Die Migration wird nur ausgelöst, wenn keine Überprüfungsfehler auftreten.

Es empfiehlt sich immer, die Option Überprüfen oder Überprüfen und migrieren auszuwählen, um vor dem Ausführen der Migration Überprüfungen durchzuführen.

Wenn die Vorschau für die Onlinemigrationen ausgewählt ist, muss die logische Replikation auf dem Single-Quellserver aktiviert sein. Wenn sie nicht aktiviert ist, aktiviert der Migrationsdienst automatisch die logische Replikation auf dem Quellserver. Replikation kann auch manuell auf der Registerkarte Replikation im Bereich „Single Server“ eingerichtet werden, indem die Azure-Replikationsunterstützungsebene auf Logisch festgelegt wird. Bei beiden Ansätzen wird der Quellserver neu gestartet.

Wählen Sie die Schaltfläche Weiter : Mit Quelle verbinden aus.

Registerkarte „Quelle“

Auf der Registerkarte Quelle werden Sie aufgefordert, Details zur Single-Serverquelle anzugeben, die die Quelle der Datenbanken ist.

Nachdem Sie eine Auswahl für Abonnement und Ressourcengruppe vorgenommen haben, werden in der Dropdownliste für Servernamen Single Server-Quellen in dieser Ressourcengruppe in den verschiedenen Regionen angezeigt. Wählen Sie die Quelle aus, von der Datenbanken migriert werden sollen. Beachten Sie, dass Sie Datenbanken von einem Einzelserver zu einem flexiblen Zielserver in derselben Region migrieren können. Regionsübergreifende Migrationen sind lediglich für Server in Indien, China und VAE aktiviert.

Nach Auswahl der Einzelserverquelle werden die Felder für Standort, PostgreSQL-Version und Anmeldename des Serveradministrators automatisch ausgefüllt. Beim Anmeldenamen des Serveradmin handelt es sich um den Benutzernamen des Admin, der zum Erstellen des Einzelservers verwendet wurde. Geben Sie im Feld Kennwort das Kennwort für den betreffenden Administratorbenutzer ein. Der Migrationsdienst führt die Migration von Single Server-Datenbanken als Administratorbenutzer aus.

Wählen Sie nach dem Ausfüllen aller Felder den Link Mit Quelle verbinden aus. Dadurch wird überprüft, ob die eingegebenen Quellserverdetails korrekt sind und der Quellserver erreichbar ist.

Wählen Sie die Schaltfläche Weiter : Migrationsziel auswählen aus, um fortzufahren.

Registerkarte „Ziel“

Auf der Registerkarte Ziel werden Metadaten für das Flexibler Server-Ziel angezeigt, z. B. Abonnementname, Ressourcengruppe, Servername, Speicherort und PostgreSQL-Version.

Als Anmeldename des Serveradmin zeigt die Registerkarte den Administratornamen an, der bei der Erstellung des Flexibler Server-Ziels verwendet wurde. Geben Sie das entsprechende Kennwort für den Administratorbenutzer ein. Wählen Sie nach dem Ausfüllen des Kennworts den Link Mit Ziel verbinden aus. Dadurch wird überprüft, ob die eingegebenen Zielserverdetails korrekt sind und der Zielserver erreichbar ist.

Wählen Sie die Schaltfläche Weiter aus, um die zu migrierenden Datenbanken auszuwählen.

Auswählen von Datenbanken für dien Registerkarte „Migration“

In dieser Registerkarte befindet sich eine Liste der Benutzerdatenbanken auf dem Einzelserver. Sie können bis zu acht Datenbanken im Rahmen eines einzelnen Migrationsversuchs auswählen und migrieren. Wenn mehr als acht Benutzerdatenbanken vorhanden sind, wird der Migrationsprozess zwischen den Quell- und Zielservern für den nächsten Satz von Datenbanken wiederholt. Standardmäßig werden ausgewählte Datenbanken mit demselben Namen auf dem Ziel überschrieben.

Wählen Sie die Schaltfläche Weiter aus, um die Details zu überprüfen.

Zusammenfassung

Auf der Registerkarte Zusammenfassung wird eine Zusammenfassung aller Details zum Erstellen der Validierung oder Migration angezeigt. Überprüfen Sie die Details, und wählen Sie die Schaltfläche „Starten“ aus.

Überwachen der Migration mithilfe des Azure-Portals

Nach Auswahl der Schaltfläche „Starten“ wird nach einigen Sekunden eine Benachrichtigung angezeigt, die Sie informiert, dass die Überprüfungs- oder Migrationserstellung erfolgreich war. Sie werden automatisch zur Seite Migration für Flexibler Server umgeleitet. Dieses Blatt weist einen neuen Eintrag für die kürzlich erstellte Überprüfung oder Migration auf.

Das Raster, in dem die Migrationen angezeigt werden, enthält folgende Spalten: Name, Status, Migrationstyp, Migrationsmodus, Quellserver, Quellservertyp, Datenbanken, Startzeit und Dauer. Die Einträge werden in absteigender Reihenfolge nach Startzeit (letzter Eintrag zuerst) angezeigt.

Sie können die Schaltfläche zum Aktualisieren verwenden, um den Status der Überprüfung oder Migration zu aktualisieren. Sie können auch den Migrationsnamen im Raster auswählen, um zugehörige Details anzuzeigen.

Nach dem Erstellen der Überprüfung oder Migration wird diese in den Zustand InProgress und in den Unterzustand PerformingPreRequisiteSteps versetzt. Der Workflow benötigt 2 bis 3 Minuten, um die Migrationsinfrastruktur und die Netzwerkverbindungen einzurichten.

Sehen wir uns an, wie Migrationen für die einzelnen Migrationsoptionen überwacht werden.

Überprüfen

Nach Abschluss des Unterzustands PerformingPreRequisiteSteps wechselt die Überprüfung in den Unterzustand Überprüfung wird ausgeführt. In diesem Zustand werden Überprüfungen für den Quell- und den Zielserver ausgeführt, um die Bereitschaft für die Migration zu bewerten.

Die Überprüfung wechselt in den Zustand Erfolgreich, wenn alle Überprüfungen entweder den Status Erfolgreich oder den Status Warnung haben.

Das Validierungsraster enthält die

• Die Abschnitte Validierungsdetails für die Instanz und Validierungsdetails für Datenbanken, stellen die Validierungsregeln dar, mit denen die Bereitschaft für die Migration überprüft wird.
• Validierungsstatus – Stellt das Ergebnis für die einzelnen Regeln dar und kann einen der drei Werte haben
  • Erfolgreich, wenn keine Fehler gefunden wurden
  • Fehler, wenn Überprüfungsfehler vorliegen
  • Warnung, wenn Überprüfungswarnungen vorliegen
• Dauer – Zeitaufwand für den Validierungsvorgang.
• Start- und Endzeit – Start- und Endzeit des Validierungsvorgangs in UTC.

Der Validierungsstatus wechselt in den Status Fehlgeschlagen, wenn Fehler bei der Validierung auftreten. Wählen Sie den Validierungsnamen oder die Validierung des Datenbanknamens aus, der fehlgeschlagen ist. Ein Aufklappfenster enthält die Details und die Korrekturmaßnahmen, die Sie ergreifen sollten, um diesen Fehler zu vermeiden.

Migrieren

Nachdem der Unterzustand PerformingPreRequisiteSteps abgeschlossen wurde, wechselt die Migration in den Unterzustand MigratingData, in dem die Datenbanken geklont bzw. kopiert werden. Die Dauer bis zum Anschluss der Migration hängt von der Größe und Form der Datenbanken ab, die Sie migrieren. Wenn die Daten weitgehend gleichmäßig über alle Tabellen verteilt sind, erfolgt die Migration schnell. Ungleiche Tabellengrößen benötigen eine relativ längere Zeit.

Wenn Sie eine beliebige Datenbank in einer Migration auswählen, wird ein Erweiterungsbereich angezeigt. Er verfügt über die gesamte Tabellenanzahl: kopiert, in die Warteschlange eingereiht, wird aktuell kopiert und Fehler, abgesehen vom Datenbankmigrationsstatus.

Die Migration wird in den Zustand Erfolgreich versetzt, wenn der Zustand MigratingData erfolgreich abgeschlossen wurde. Wenn beim Zustand MigratingData ein Problem auftritt, wird die Migration in den Zustand Failed versetzt.

Sobald die Migration in den Status Erfolgreich aufweist, ist die Migration des Schemas und der Daten von Ihrem Einzelserver zu Ihrem Ziel für den flexiblen Server abgeschlossen. Sie können die Schaltfläche „Aktualisieren“ auf der Seite verwenden, um dies zu bestätigen.

Überprüfen und migrieren

Bei dieser Option werden zuerst Überprüfungen vor Beginn der Migration ausgeführt. Nach Abschluss des Unterzustands PerformingPreRequisiteSteps wechselt der Workflow in den Unterzustand Überprüfung wird ausgeführt.

• Wenn bei der Überprüfung Fehler auftreten, wechselt die Migration in den Zustand Fehler.
• Wenn die Validierung ohne Fehler abgeschlossen ist, wird die Migration gestartet, und der Workflow wechselt in den Substatus Migrieren von Daten.

Sie können die Ergebnisse für Überprüfen und Migrieren sehen, sobald der Vorgang abgeschlossen ist.

Übernahmemigrationsaufgabe

Für Migrieren sowie Überprüfen und Migrieren erfordert der Abschluss der Onlinemigration einen weiteren Schritt – eine Übernahmeaktion durch die Benutzerin oder den Benutzer. Nachdem das Kopieren/Klonen der Basisdaten abgeschlossen ist, wird die Migration in den Zustand WaitingForUserAction und Unterstatus WaitingForCutoverTrigger verschoben. In diesem Zustand kann der Benutzer die Übernahme über das Portal auslösen, indem er die Migration auswählt.

Vor dem Initiieren der Übernahme ist es wichtig, Folgendes sicherzustellen:

• Schreibvorgänge in die Quelle werden beendet –Latency (minutes) Der Parameter ist 0 oder nahe 0. Die Latency (minutes) Informationen können auf dem Bildschirm mit den Migrationsdetails abgerufen werden, wie unten dargestellt:

Latency (minutes) Der Parameter gibt an, wann das Ziel zuletzt mit der Quelle synchronisiert wurde. Am Beispiel der obenstehenden Auftragsdatenbank ist es 0,33333. Dies bedeutet, dass die Änderungen, die in den letzten ~0,3 Minuten an der Quelle aufgetreten sind, noch mit dem Ziel synchronisiert werden müssen für die Auftragsdatenbank. Zu diesem Zeitpunkt können Schreibvorgänge an die Quelle beendet und der Übernahmevorgang initiiert werden. Falls es einen starken Datenverkehr an der Quelle gibt, empfiehlt es sich, die Schreibvorgänge zuerst zu beenden, damit Latency (minutes) sich 0 nähert und dann die Übernahme initiiert wird. Der Übernahmevorgang wendet alle ausstehenden Änderungen von der Quelle auf das Ziel an und schließt die Migration ab. Wenn Sie einen "Cutover" auch mit nicht null Latenzauslösen, wird die Replikation bis zu diesem Zeitpunkt angehalten. Alle Quelldaten, bis der Übernahmepunkt dann auf das Ziel angewendet wird. Angenommen, die Latenzzeit zum Zeitpunkt der Übernahme betrug 15 Minuten, dann werden alle Änderungsdaten der letzten 15 Minuten auf das Ziel angewendet. Die benötigte Zeit hängt vom Backlog der Änderungen in den letzten 15 Minuten ab. Daher wird empfohlen, dass die Latenz auf Null oder nahe Null geht, bevor die Übernahme ausgelöst wird.

Die Migration wird in den Succeeded Zustand verschoben, sobald der Migrating Data Unterstatus oder der Übernahmevorgang (in der Onlinemigration) erfolgreich abgeschlossen ist. Wenn im Unterzustand Migrating Data ein Problem auftritt, geht die Migration in den Zustand Failed über.

Es gibt folgende Migrationszustände:

• InProgress: Die Migrationsinfrastruktur wird eingerichtet, oder die tatsächliche Datenmigration wird aktuell ausgeführt.
• Abgebrochen: Die Migration wurde abgebrochen oder gelöscht.
• Failed: Bei der Migration ist ein Fehler aufgetreten.
• Fehler bei Überprüfung: Bei der Überprüfung ist ein Fehler aufgetreten.
• Succeeded: Die Migration wurde erfolgreich durchgeführt und ist beendet.

Es gibt folgende Migrationsunterzustände:

• PerformingPreRequisiteSteps: Die Infrastruktur wird für die Datenmigration eingerichtet.
• Überprüfung wird ausgeführt: Die Überprüfung wird ausgeführt.
• MigratingData: Die Datenmigration wird aktuell ausgeführt.
• CompletingMigration: Die Migration befindet sich in den letzten Phasen vor dem Abschluss.
• Abgeschlossen: Die Migration wurde erfolgreich abgeschlossen.

Abbrechen der Migration über das Portal

Sie können alle aktuellen Überprüfungen oder Migrationen abbrechen. Der Workflow muss sich im Zustand InProgress befinden, damit er abgebrochen werden kann. Sie können keine Überprüfung oder Migration abbrechen, die sich im Zustand Erfolgreich oder Fehler befindet.

Durch das Abbrechen einer Überprüfung werden alle weiteren Überprüfungsaktivitäten beendet, und die Überprüfung wechselt in den Zustand Abgebrochen. Bei Abbruch einer Migration werden alle weiteren Migrationsaktivitäten auf dem Zielserver gestoppt, und sie wechseln in den Zustand Abgebrochen. Es werden keine Änderungen auf dem Zielserver verworfen oder rückgängig gemacht. Stellen Sie sicher, dass Sie die Datenbanken auf Ihrem Zielserver löschen, die an einer abgebrochenen Migration beteiligt sind.

BEFEHLSZEILENSCHNITTSTELLE (CLI)

Sie können die Azure CLI für die Migration verwenden.

Offline

Voraussetzungen (Offline)

Bevor Sie Ihre Migration mit dem Migrationsdienst in Azure Database for PostgreSQL starten, müssen Sie unbedingt die folgenden Voraussetzungen erfüllen, die für Offlinemigrationsszenarien gelten.

Überprüfen der Quellversion

Die PostgreSQL-Quellversion sollte >= 9.5 sein. Wenn die PostgreSQL-Quellversion kleiner als 9.5 ist, aktualisieren Sie die PostgreSQL-Quellversion auf 9.5 oder höher, bevor Sie migrieren.

Zielsetup

• Azure Database for PostgreSQL muss vor der Migration in Azure eingerichtet werden.

• Die für die Azure Database for PostgreSQL-Instanz gewählte SKU sollte den Spezifikationen der Quelldatenbank entsprechen, um Kompatibilität und angemessene Leistung sicherzustellen.

• Ausführliche Anweisungen zum Erstellen einer neuen Azure Database for PostgreSQL-Instanz finden Sie unter dem folgenden Link: Schnellstart: Erstellen eines Servers.

Netzwerkeinrichtung

Das ordnungsgemäße Netzwerksetup ist unerlässlich, um während der Migration eine erfolgreiche Verbindung zwischen der Quelle und dem Ziel sicherzustellen. Im Folgenden finden Sie eine Anleitung zum Einrichten der Netzwerkverbindung für verschiedene Szenarien:

Netzwerkanforderungen für die Migration:

• ExpressRoute-/IPsec-VPN-/VPN-Tunneling: Wenn Sie Ihre lokale/AWS-Quelle mit Azure verbinden, müssen Sie möglicherweise eine ExpressRoute, ein IPsec-VPN oder VPN-Tunneling einrichten, um eine sichere Datenübertragung zu ermöglichen.

• VNet-Peering: Richten Sie Peering virtueller Netzwerke zwischen den beiden unterschiedlichen VNets ein, um die direkte Netzwerkkonnektivität zu ermöglichen, eine Voraussetzung für die Migration zwischen der Azure-VM und der Azure Database for PostgreSQL-Instanz.

Konnektivitätsszenarien:

Die folgende Tabelle kann beim Einrichten des Netzwerks zwischen der Quelle und dem Ziel helfen.

Quelle	Ziel	Konnektivitätstipps
Öffentlich	Öffentlich	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Public	Diese Konfiguration wird nicht unterstützt. Verwenden Sie pg_dump/pg_restore für die Datenübertragung.
Öffentlich	Privat	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Privat	Richten Sie eine ExpressRoute, ein IPsec-VPN, VPN-Tunneling oder Peering virtueller Netzwerke zwischen der Quelle und dem Ziel ein.
Privat	Privater Endpunkt	Diese Konfiguration wird nicht unterstützt. Wenden Sie sich an den Microsoft-Support.

Zusätzliche Überlegungen zum Netzwerk:

• pg_hba.conf-Konfiguration: Um die Konnektivität zwischen den PostgreSQL-Quell- und Zielinstanzen zu unterstützen, ist es wichtig, die Datei pg_hba.conf zu überprüfen und gegebenenfalls zu ändern. Diese Datei enthält die Clientauthentifizierung und muss so konfiguriert sein, dass die PostgreSQL-Zielinstanz eine Verbindung mit der Quelle herstellen kann. Änderungen an der Datei pg_hba.conf erfordern in der Regel einen Neustart der PostgreSQL-Quellinstanz, um wirksam zu werden.

Hinweis

Die Datei pg_hba.conf befindet sich im Datenverzeichnis der PostgreSQL-Installation. Diese Datei sollte überprüft und konfiguriert werden, wenn es sich bei der Quelldatenbank um einen lokalen PostgreSQL-Server handelt, oder einen PostgreSQL-Server, der auf einer Azure-VM gehostet wird. Bei PostgreSQL-Instanzen auf AWS RDS oder ähnlichen verwalteten Diensten ist die Datei pg_hba.conf nicht direkt zugänglich oder anwendbar. Stattdessen wird der Zugriff über die bereitgestellten Sicherheits- und Netzwerkzugriffskonfigurationen des Diensts gesteuert.

Weitere Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst in Azure Database for PostgreSQL – Flexibler Server.

Erweiterungen

Erweiterungen sind zusätzliche Features, die PostgreSQL hinzugefügt werden können, um seine Funktionalität zu verbessern. Erweiterungen werden in Azure Database for PostgreSQL unterstützt, müssen jedoch manuell aktiviert werden. Führen Sie die folgenden Schritte aus, um Erweiterungen zu aktivieren:

• Verwenden Sie den Befehl „auswählen“ in der Quelle, um alle Erweiterungen aufzulisten, die verwendet werden – select extname,extversion from pg_extension;

• Suchen Sie auf der Seite „Serverparameter“ in Ihrer Azure Database for PostgreSQL-Instanz nach dem Serverparameter azure.extensions. Aktivieren Sie die Erweiterungen, die in der Quelle in PostgreSQL gefunden wurden.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

  

• Überprüfen Sie, ob die Liste eine der folgenden Erweiterungen enthält:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Wenn ja, durchsuchen Sie die Seite „Serverparameter“ nach dem Parameter shared_preload_libraries. Dieser Parameter gibt den Satz von Erweiterungsbibliotheken an, der beim Neustart des Servers vorab geladen wird.

Serverparameter

Diese Parameter werden nicht automatisch in die Zielumgebung migriert und müssen manuell konfiguriert werden.

• Stimmen Sie Serverparameterwerte aus der PostgreSQL-Quelldatenbank mit der Azure Database for PostgreSQL-Instanz ab, indem Sie im Azure-Portal auf den Abschnitt „Serverparameter“ zugreifen und die Werte entsprechend manuell aktualisieren.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und Lesereplikaten im Ziel

• Das Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und der Lesereplikate in der Zielumgebung ist unerlässlich. Diese Features sollten erst aktiviert werden, nachdem die Migration abgeschlossen wurde.

• Wenn Sie diese Richtlinien befolgen, können Sie einen reibungslosen Migrationsprozess ohne die zusätzlichen Variablen sicherstellen, die durch Hochverfügbarkeit und Lesereplikate eingeführt wurden. Sobald die Migration abgeschlossen und die Datenbank stabil ist, können Sie diese Features aktivieren, um die Verfügbarkeit und Skalierbarkeit Ihrer Datenbankumgebung in Azure zu verbessern.

Erste Schritte

1. Wenn Sie neu bei Microsoft Azure sind, erstellen Sie ein Konto, um die Angebote zu evaluieren.

2. Installieren Sie über die Azure CLI-Installationsseite die neueste Azure CLI für Ihr Betriebssystem.

   Wenn die Azure CLI bereits installiert ist, überprüfen Sie die Version mithilfe des Befehls az version. Um CLI-Befehle für die Migration verwenden zu können, benötigen Sie Version 2.50.0 oder höher. Wenn diese Voraussetzung nicht erfüllt ist, aktualisieren Sie Ihre Azure CLI-Version.

3. Führen Sie den Befehl az login aus:

   az login
   

   Es wird ein Browserfenster mit der Azure-Anmeldeseite geöffnet. Geben Sie Ihre Azure-Anmeldeinformationen an, um eine erfolgreiche Authentifizierung durchzuführen. Weitere Möglichkeiten zum Anmelden mit der Azure CLI finden Sie in diesem Artikel.

CLI-Befehle für die Migration (offline)

Der Migrationsdienst bietet benutzerfreundliche CLI-Befehle zum Ausführen migrationsbezogener Aufgaben. Alle CLI-Befehle beginnen mit az postgres flexible-server migration. Es ist wichtig, die Erweiterungen in die Positivliste aufzunehmen, bevor Sie eine Migration starten.

Wenn Sie Hilfe benötigen, um die mit einem Befehl verbundenen Optionen zu verstehen und die richtige Syntax zu bestimmen, können Sie den Parameter help verwenden:

az postgres flexible-server migration --help

Der obige Befehl liefert die folgende Ausgabe:

Die Ausgabe listet die unterstützten Migrationsbefehle zusammen mit ihren Aktionen auf. Sehen wir uns diese Befehle im Detail an.

Erstellen einer Migration mithilfe der Azure CLI

Der Befehl create unterstützt Sie beim Erstellen einer Migration von einem Quellserver zu einem Zielserver:

az postgres flexible-server migration create -- help

Der obige Befehl liefert das folgende Ergebnis:

Er führt die erwarteten Argumente auf und zeigt eine Beispielsyntax zum erfolgreichen Erstellen einer Migration vom Quellserver zum Zielserver. Hier sehen Sie den CLI-Befehl zum Erstellen einer neuen Migration:

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

Parameter	BESCHREIBUNG
subscription	Abonnement-ID des Flexible Server-Ziels.
resource-group	Ressourcengruppe des Flexible Server-Ziels.
name	Name des Flexible Server-Ziels.
migration-name	Eindeutiger Bezeichner für Migrationsversuche zu Flexible Server. In dieses Feld dürfen nur alphanumerische Zeichen eingegeben werden, und mit Ausnahme von Bindestrichen (-) dürfen keine Sonderzeichen verwendet werden. Der Name darf nicht mit - beginnen, und zwei Migrationen zu einem Flexible Server-Ziel dürfen nicht denselben Namen verwenden.
migration-mode	Dies ist ein optionaler Parameter. Standardwert: Offline. Die Offlinemigration umfasst das Kopieren Ihrer Quelldatenbanken zu einem bestimmten Zeitpunkt auf Ihren Zielserver.
properties	Absoluter Pfad zu einer JSON-Datei mit Informationen zur Single Server-Quelle.

Zum Beispiel:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

Das Argument migration-name im Befehl create wird in anderen CLI-Befehlen wie z. B. update, delete, und show. verwendet. In all diesen Befehlen wird der Migrationsversuch in den entsprechenden Aktionen eindeutig identifiziert.

Zum Schluss benötigt der Befehl create eine JSON-Datei, die als Teil des properties-Arguments übergeben wird.

Die Struktur der JSON lautet wie folgt:

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Die Parameter create, die in das JSON-Dateiformat übertragen werden, sehen folgendermaßen aus:

Parameter	Typ	Beschreibung
sourceDbServerResourceId	Erforderlich	Dieser Parameter ist die Ressourcen-ID der Single Server-Quelle. Er ist obligatorisch.
adminCredentials	Erforderlich	Dieser Parameter listet Kennwörter für Administratorbenutzer sowohl für die Single Server-Quelle als auch für das Flexible Server-Ziel auf. Diese Kennwörter dienen zur Authentifizierung gegenüber dem Quell- und Zielserver.
sourceServerUserName	Erforderlich	Der Standardwert ist der bei der Erstellung eines Einzelservers erstellte Administratorbenutzer, und das angegebene Kennwort wird für die Authentifizierung für diese Benutzerin oder diesen Benutzer verwendet. Wenn Sie nicht die Standardbenutzerin oder den Standardbenutzer verwenden, gibt dieser Parameter die Benutzerin oder den Benutzer oder die Rolle auf dem Quellserver an, der bzw. die für die Migration verwendet wird. Diese Benutzerin oder dieser Benutzer sollte über die notwendigen Berechtigungen für die und den Besitz an den von der Migration betroffenen Datenbankobjekten verfügen die Rolle azure_pg_admin inne haben.
targetServerUserName	Erforderlich	Der Standardwert ist der bei der Erstellung des flexiblen Servers erstellte Administratorbenutzer, und das angegebene Kennwort wird für die Authentifizierung für diese Benutzerin oder diesen Benutzer verwendet. Wenn Sie nicht den Standardbenutzer verwenden, gibt dieser Parameter den Benutzer oder die Rolle auf dem Zielserver an, der bzw. die für die Migration verwendet wird. Dieser Benutzer sollte Mitglied der Rollen azure_pg_admin, pg_read_all_settings, pg_read_all_stats und pg_stat_scan_tables sein sowie über die Attribute Create role, Create DB verfügen.
dbsToMigrate	Erforderlich	Geben Sie die Liste der Datenbanken an, die Sie zu Flexible Server migrieren möchten. Es werden nur Benutzerdatenbanken migriert. Systemdatenbanken oder Vorlagendatenbanken wie template0 und template1 werden nicht migriert.
overwriteDbsInTarget	Erforderlich	Wenn die Einstellung auf „Wahr“ festgelegt ist, überschreibt der Migrationsdienst die Datenbank automatisch, wenn auf dem Zielserver bereits eine Datenbank mit demselben Namen wie die zu migrierende Datenbank vorhanden ist.
SetupLogicalReplicationOnSourceDBIfNeeded	Optional	Sie können die logische Replikation für den Quellserver automatisch aktivieren, indem Sie diese Eigenschaft auf true festlegen. Diese Änderung der Servereinstellungen erfordert einen Neustart des Servers mit einer Ausfallzeit von zwei bis drei Minuten.
SourceDBServerFullyQualifiedDomainName	Optional	Verwenden Sie diesen Parameter, wenn ein benutzerdefinierter DNS-Server zur Namensauflösung für ein virtuelles Netzwerk verwendet wird. Geben Sie für diese Eigenschaft den FQDN der Single Server-Quelle entsprechend dem benutzerdefinierten DNS-Server an.
TargetDBServerFullyQualifiedDomainName	Optional	Verwenden Sie diesen Parameter, wenn ein benutzerdefinierter DNS-Server zur Namensauflösung in einem virtuellen Netzwerk verwendet wird. Geben Sie den FQDN des Flexible Server-Ziels entsprechend dem benutzerdefinierten DNS-Server an. SourceDBServerFullyQualifiedDomainName und TargetDBServerFullyQualifiedDomainName werden nur in dem seltenen Fall in der JSON-Datei angegeben, dass ein benutzerdefinierter DNS-Server anstelle des von Azure bereitgestellten DNS für die Namensauflösung verwendet wird. Andernfalls sollten Sie diese Parameter nicht in die JSON-Datei einfügen.

Beachten Sie diese essentiellen Punkte bezüglich der Befehlsantwort:

• Wenn der Befehl create ausgelöst wird, wechselt die Migration in den Zustand InProgress und in den Unterzustand PerformingPreRequisiteSteps. Der Migrations-Workflow benötigt ein paar Minuten, um die Migrationsinfrastruktur bereitzustellen und Verbindungen zwischen der Quelle und dem Ziel einzurichten.
• Nach Beendigung des Unterzustands PerformingPreRequisiteSteps geht die Migration in den Unterzustand Migrating Data, über, in dem das Klonen/Kopieren der Datenbanken durchgeführt werden.
• Für jede zu migrierende Datenbank gibt es einen eigenen Abschnitt mit sämtlichen Migrationsdetails, z. B. Anzahl der Tabellen, inkrementelle Einfügungen, Löschungen und ausstehende Bytes.
• Die zur Beendigung des Unterzustands Migrating Data benötigte Zeit hängt von der Größe der Datenbanken ab, die migriert werden.
• Die Migration geht in den Zustand Succeeded über, sobald der Unterzustand Migrating Data erfolgreich beendet wurde. Wenn im Unterzustand Migrating Data ein Problem auftritt, geht die Migration in den Zustand Failed über.

Einrichten der Replikation

Wenn die Vorschau für die Onlinemigrationen ausgewählt ist, muss die logische Replikation auf dem Single-Quellserver aktiviert sein. Wenn sie nicht aktiviert ist, aktiviert der Migrationsdienst automatisch die logische Replikation auf dem einzelnen Quellserver, wenn der Parameter SetupLogicalReplicationOnSourceDBIfNeeded mit einem Wert von true in der zugehörigen JSON-Datei übergeben wird. Die Replikation kann auch manuell an der Quelle nach dem Starten der Migration mithilfe des folgenden Befehls eingerichtet werden. Bei beiden Methoden zur Aktivierung der logischen Replikation wird der einzelne Quellserver neu gestartet.

Zum Beispiel:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Dieser Befehl ist erforderlich, um die Migration voranzutreiben, wenn der flexible Server im WaitingForLogicalReplicationSetupRequestOnSourceDB Zustand wartet.

Um die Onlinemigration in einer der oben genannten Regionen durchzuführen, verwenden Sie:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode online

Auflisten der Migrationen

Mit dem Befehl list können Sie die erfolgten Migrationsversuche zu einem Flexible Server-Ziel auflisten:

az postgres flexible-server migration list [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--filter]

Der Parameter filter verfügt über zwei Optionen:

• Active: Listet die derzeit aktiven Migrationsversuche (in Bearbeitung) für den Zielserver auf. Sie enthält nicht die Migrationen, die fehlgeschlagen sind, abgebrochen wurden oder erfolgreich waren.
• All: Listet alle Migrationsversuche zum Zielserver auf. Dies schließt sowohl die aktiven als auch frühere Migrationen ein, unabhängig von ihrem Zustand.

Weitere Informationen zu diesem Befehl erhalten Sie über den Parameter help:

az postgres flexible-server migration list -- help

Überwachen der Migration

Der Befehl show hilft Ihnen bei der Überwachung laufender Migrationen und gibt den aktuellen Zustand und Unterzustand der Migration an. Dies umfasst Informationen zum aktuellen Zustand und Unterzustand der Migration.

az postgres flexible-server migration show [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Der Parameter migration_name gibt den Namen an, der der Migration mit dem Befehl create zugewiesen wurde. Hier sehen Sie einen Screenshot der Beispielantwort des CLI-Befehls zum Anzeigen von Details:

Weitere Informationen zu diesem Befehl erhalten Sie über den Parameter help:

 az postgres flexible-server migration show -- help

In den folgenden Tabellen werden die Migrationszustände und Unterzustände beschrieben.

Migrationszustand	BESCHREIBUNG
InProgress	Die Migrationsinfrastruktur wird gerade eingerichtet, oder die tatsächliche Datenmigration wird ausgeführt.
Canceled	Die Migration wurde abgebrochen oder gelöscht.
Failed	Bei der Migration ist ein Fehler aufgetreten.
Succeeded	Die Migration wurde erfolgreich durchgeführt und ist beendet.

Migrationsunterzustand	BESCHREIBUNG
PerformingPreRequisiteSteps	Die Infrastruktur wird eingerichtet und für die Datenmigration vorbereitet.
MigratingData	Die Datenmigration wird durchgeführt.
CompletingMigration	Cutover der Migration wird ausgeführt.
Completed	die Übernahme war erfolgreich, und die Migration ist abgeschlossen.

Online (Vorschau)

Voraussetzungen (online)

Bevor Sie Ihre Migration mit dem Migrationsdienst in Azure Database for PostgreSQL starten, müssen Sie unbedingt die folgenden Voraussetzungen erfüllen, die für Offlinemigrationsszenarien gelten.

Überprüfen der Quellversion

Die PostgreSQL-Quellversion sollte >= 9.5 sein. Wenn die PostgreSQL-Quellversion kleiner als 9.5 ist, aktualisieren Sie die PostgreSQL-Quellversion auf 9.5 oder höher, bevor Sie migrieren.

Einrichten von Parametern für die Onlinemigration

Für die Onlinemigration sollte die Replikationsunterstützung unter „Replikationseinstellungen“ in der Quelle „PostgreSQL-Server“ eingestellt werden. Darüber hinaus sollten die Werte der Serverparameter max_wal_senders und max_replication_slots größer sein als die Anzahl der zu migrierenden Datenbanken. Die Parameter können im Azure-Portal unter Einstellungen>Serverparameter festgelegt oder in der Befehlszeile mit den folgenden Befehlen konfiguriert werden:

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Stellen Sie sicher, dass keine zeitintensive Transaktionen vorhanden sind. Zeitintensive Transaktionen lassen die Erstellung von Replikationsplätzen nicht zu. Die Erstellung eines Replikationsslots ist erfolgreich, wenn alle lang laufenden Transaktionen bestätigt oder zurückgenommen wurden. Sie müssen den PostgreSQL-Quellserver neu starten, nachdem alle Voraussetzungen für die Onlinemigration erfüllt sind.

Hinweis

Für die Onlinemigration mit Azure Database for PostgreSQL – Single Server ist die Azure-Replikationsunterstützung unter den Replikationseinstellungen auf der Seite „Single Server“ im Azure-Portal auf „Logisch“ eingestellt.

Zielsetup

• Azure Database for PostgreSQL muss vor der Migration in Azure eingerichtet werden.

• Die für die Azure Database for PostgreSQL-Instanz gewählte SKU sollte den Spezifikationen der Quelldatenbank entsprechen, um Kompatibilität und angemessene Leistung sicherzustellen.

• Ausführliche Anweisungen zum Erstellen einer neuen Azure Database for PostgreSQL-Instanz finden Sie unter dem folgenden Link: Schnellstart: Erstellen eines Servers.

• Der Werts des Serverparameters max_replication_slots sollte größer sein als die Anzahl der zu migrierenden Datenbanken. Er kann im Azure-Portal unter Einstellungen>Serverparameter festgelegt oder in der Befehlszeile mit dem folgenden Befehl konfiguriert werden:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Netzwerkeinrichtung

Das ordnungsgemäße Netzwerksetup ist unerlässlich, um während der Migration eine erfolgreiche Verbindung zwischen der Quelle und dem Ziel sicherzustellen. Im Folgenden finden Sie eine Anleitung zum Einrichten der Netzwerkverbindung für verschiedene Szenarien:

Netzwerkanforderungen für die Migration:

• ExpressRoute-/IPsec-VPN-/VPN-Tunneling: Wenn Sie Ihre lokale/AWS-Quelle mit Azure verbinden, müssen Sie möglicherweise eine ExpressRoute, ein IPsec-VPN oder VPN-Tunneling einrichten, um eine sichere Datenübertragung zu ermöglichen.

• VNet-Peering: Richten Sie Peering virtueller Netzwerke zwischen den beiden unterschiedlichen VNets ein, um die direkte Netzwerkkonnektivität zu ermöglichen, eine Voraussetzung für die Migration zwischen der Azure-VM und der Azure Database for PostgreSQL-Instanz.

Konnektivitätsszenarien:

Die folgende Tabelle kann beim Einrichten des Netzwerks zwischen der Quelle und dem Ziel helfen.

Quelle	Ziel	Konnektivitätstipps
Öffentlich	Öffentlich	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Public	Diese Konfiguration wird nicht unterstützt. Verwenden Sie pg_dump/pg_restore für die Datenübertragung.
Öffentlich	Privat	Es ist keine andere Aktion erforderlich, wenn die Quelle in den Firewallregeln des Ziels in der Positivliste aufgeführt ist.
Privat	Privat	Richten Sie eine ExpressRoute, ein IPsec-VPN, VPN-Tunneling oder Peering virtueller Netzwerke zwischen der Quelle und dem Ziel ein.
Privat	Privater Endpunkt	Diese Konfiguration wird nicht unterstützt. Wenden Sie sich an den Microsoft-Support.

Weitere Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst in Azure Database for PostgreSQL – Flexibler Server.

Erweiterungen

Erweiterungen sind zusätzliche Features, die PostgreSQL hinzugefügt werden können, um seine Funktionalität zu verbessern. Erweiterungen werden in Azure Database for PostgreSQL unterstützt, müssen jedoch manuell aktiviert werden. Führen Sie die folgenden Schritte aus, um Erweiterungen zu aktivieren:

• Verwenden Sie den Befehl „auswählen“ in der Quelle, um alle Erweiterungen aufzulisten, die verwendet werden – select extname,extversion from pg_extension;

• Suchen Sie auf der Seite „Serverparameter“ in Ihrer Azure Database for PostgreSQL-Instanz nach dem Serverparameter azure.extensions. Aktivieren Sie die Erweiterungen, die in der Quelle in PostgreSQL gefunden wurden.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

  

• Überprüfen Sie, ob die Liste eine der folgenden Erweiterungen enthält:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Wenn ja, durchsuchen Sie die Seite „Serverparameter“ nach dem Parameter shared_preload_libraries. Dieser Parameter gibt den Satz von Erweiterungsbibliotheken an, der beim Neustart des Servers vorab geladen wird.

Serverparameter

Diese Parameter werden nicht automatisch in die Zielumgebung migriert und müssen manuell konfiguriert werden.

• Stimmen Sie Serverparameterwerte aus der PostgreSQL-Quelldatenbank mit der Azure Database for PostgreSQL-Instanz ab, indem Sie im Azure-Portal auf den Abschnitt „Serverparameter“ zugreifen und die Werte entsprechend manuell aktualisieren.

• Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.

Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und Lesereplikaten im Ziel

• Das Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und der Lesereplikate in der Zielumgebung ist unerlässlich. Diese Features sollten erst aktiviert werden, nachdem die Migration abgeschlossen wurde.

• Wenn Sie diese Richtlinien befolgen, können Sie einen reibungslosen Migrationsprozess ohne die zusätzlichen Variablen sicherstellen, die durch Hochverfügbarkeit und Lesereplikate eingeführt wurden. Sobald die Migration abgeschlossen und die Datenbank stabil ist, können Sie diese Features aktivieren, um die Verfügbarkeit und Skalierbarkeit Ihrer Datenbankumgebung in Azure zu verbessern.

Erste Schritte

1. Wenn Sie neu bei Microsoft Azure sind, erstellen Sie ein Konto, um die Angebote zu evaluieren.

2. Installieren Sie über die Azure CLI-Installationsseite die neueste Azure CLI für Ihr Betriebssystem.

   Wenn die Azure CLI bereits installiert ist, überprüfen Sie die Version mithilfe des Befehls az version. Um CLI-Befehle für die Migration verwenden zu können, benötigen Sie Version 2.50.0 oder höher. Wenn diese Voraussetzung nicht erfüllt ist, aktualisieren Sie Ihre Azure CLI-Version.

3. Führen Sie den Befehl az login aus:

   az login
   

   Es wird ein Browserfenster mit der Azure-Anmeldeseite geöffnet. Geben Sie Ihre Azure-Anmeldeinformationen an, um eine erfolgreiche Authentifizierung durchzuführen. Weitere Möglichkeiten zum Anmelden mit der Azure CLI finden Sie in diesem Artikel.

CLI-Befehle für die Migration (online)

Der Migrationsdienst bietet benutzerfreundliche CLI-Befehle zum Ausführen migrationsbezogener Aufgaben. Alle CLI-Befehle beginnen mit az postgres flexible-server migration. Es ist wichtig, die Erweiterungen in die Positivliste aufzunehmen, bevor Sie eine Migration starten.

Wenn Sie Hilfe benötigen, um die mit einem Befehl verbundenen Optionen zu verstehen und die richtige Syntax zu bestimmen, können Sie den Parameter help verwenden:

az postgres flexible-server migration --help

Der obige Befehl liefert die folgende Ausgabe:

Die Ausgabe listet die unterstützten Migrationsbefehle zusammen mit ihren Aktionen auf. Sehen wir uns diese Befehle im Detail an.

Erstellen einer Migration mithilfe der Azure CLI

Der Befehl create unterstützt Sie beim Erstellen einer Migration von einem Quellserver zu einem Zielserver:

az postgres flexible-server migration create -- help

Der obige Befehl liefert das folgende Ergebnis:

Er führt die erwarteten Argumente auf und zeigt eine Beispielsyntax zum erfolgreichen Erstellen einer Migration vom Quellserver zum Zielserver. Hier sehen Sie den CLI-Befehl zum Erstellen einer neuen Migration:

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

Parameter	BESCHREIBUNG
subscription	Abonnement-ID des Flexible Server-Ziels.
resource-group	Ressourcengruppe des Flexible Server-Ziels.
name	Name des Flexible Server-Ziels.
migration-name	Eindeutiger Bezeichner für Migrationsversuche zu Flexible Server. In dieses Feld dürfen nur alphanumerische Zeichen eingegeben werden, und mit Ausnahme von Bindestrichen (-) dürfen keine Sonderzeichen verwendet werden. Der Name darf nicht mit - beginnen, und zwei Migrationen zu einem Flexible Server-Ziel dürfen nicht denselben Namen verwenden.
migration-mode	Dies ist ein optionaler Parameter. Standardwert: Offline. Die Offlinemigration umfasst das Kopieren Ihrer Quelldatenbanken zu einem bestimmten Zeitpunkt auf Ihren Zielserver.
properties	Absoluter Pfad zu einer JSON-Datei mit Informationen zur Single Server-Quelle.

Zum Beispiel:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

Das Argument migration-name im Befehl create wird in anderen CLI-Befehlen wie z. B. update, delete, und show. verwendet. In all diesen Befehlen wird der Migrationsversuch in den entsprechenden Aktionen eindeutig identifiziert.

Zum Schluss benötigt der Befehl create eine JSON-Datei, die als Teil des properties-Arguments übergeben wird.

Die Struktur der JSON lautet wie folgt:

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Die Parameter create, die in das JSON-Dateiformat übertragen werden, sehen folgendermaßen aus:

Parameter	Typ	Beschreibung
sourceDbServerResourceId	Erforderlich	Dieser Parameter ist die Ressourcen-ID der Single Server-Quelle. Er ist obligatorisch.
adminCredentials	Erforderlich	Dieser Parameter listet Kennwörter für Administratorbenutzer sowohl für die Single Server-Quelle als auch für das Flexible Server-Ziel auf. Diese Kennwörter dienen zur Authentifizierung gegenüber dem Quell- und Zielserver.
sourceServerUserName	Erforderlich	Der Standardwert ist der bei der Erstellung eines Einzelservers erstellte Administratorbenutzer, und das angegebene Kennwort wird für die Authentifizierung für diese Benutzerin oder diesen Benutzer verwendet. Wenn Sie nicht die Standardbenutzerin oder den Standardbenutzer verwenden, gibt dieser Parameter die Benutzerin oder den Benutzer oder die Rolle auf dem Quellserver an, der bzw. die für die Migration verwendet wird. Diese Benutzerin oder dieser Benutzer sollte über die notwendigen Berechtigungen für die und den Besitz an den von der Migration betroffenen Datenbankobjekten verfügen die Rolle azure_pg_admin inne haben.
targetServerUserName	Erforderlich	Der Standardwert ist der bei der Erstellung des flexiblen Servers erstellte Administratorbenutzer, und das angegebene Kennwort wird für die Authentifizierung für diese Benutzerin oder diesen Benutzer verwendet. Wenn Sie nicht den Standardbenutzer verwenden, gibt dieser Parameter den Benutzer oder die Rolle auf dem Zielserver an, der bzw. die für die Migration verwendet wird. Dieser Benutzer sollte Mitglied der Rollen azure_pg_admin, pg_read_all_settings, pg_read_all_stats und pg_stat_scan_tables sein sowie über die Attribute Create role, Create DB verfügen.
dbsToMigrate	Erforderlich	Geben Sie die Liste der Datenbanken an, die Sie zu Flexible Server migrieren möchten. Es werden nur Benutzerdatenbanken migriert. Systemdatenbanken oder Vorlagendatenbanken wie template0 und template1 werden nicht migriert.
overwriteDbsInTarget	Erforderlich	Wenn die Einstellung auf „Wahr“ festgelegt ist, überschreibt der Migrationsdienst die Datenbank automatisch, wenn auf dem Zielserver bereits eine Datenbank mit demselben Namen wie die zu migrierende Datenbank vorhanden ist.
SetupLogicalReplicationOnSourceDBIfNeeded	Optional	Sie können die logische Replikation für den Quellserver automatisch aktivieren, indem Sie diese Eigenschaft auf true festlegen. Diese Änderung der Servereinstellungen erfordert einen Neustart des Servers mit einer Ausfallzeit von zwei bis drei Minuten.
SourceDBServerFullyQualifiedDomainName	Optional	Verwenden Sie diesen Parameter, wenn ein benutzerdefinierter DNS-Server zur Namensauflösung für ein virtuelles Netzwerk verwendet wird. Geben Sie für diese Eigenschaft den FQDN der Single Server-Quelle entsprechend dem benutzerdefinierten DNS-Server an.
TargetDBServerFullyQualifiedDomainName	Optional	Verwenden Sie diesen Parameter, wenn ein benutzerdefinierter DNS-Server zur Namensauflösung in einem virtuellen Netzwerk verwendet wird. Geben Sie den FQDN des Flexible Server-Ziels entsprechend dem benutzerdefinierten DNS-Server an. SourceDBServerFullyQualifiedDomainName und TargetDBServerFullyQualifiedDomainName werden nur in dem seltenen Fall in der JSON-Datei angegeben, dass ein benutzerdefinierter DNS-Server anstelle des von Azure bereitgestellten DNS für die Namensauflösung verwendet wird. Andernfalls sollten Sie diese Parameter nicht in die JSON-Datei einfügen.

Beachten Sie diese essentiellen Punkte bezüglich der Befehlsantwort:

• Wenn der Befehl create ausgelöst wird, wechselt die Migration in den Zustand InProgress und in den Unterzustand PerformingPreRequisiteSteps. Der Migrations-Workflow benötigt ein paar Minuten, um die Migrationsinfrastruktur bereitzustellen und Verbindungen zwischen der Quelle und dem Ziel einzurichten.
• Nach Beendigung des Unterzustands PerformingPreRequisiteSteps geht die Migration in den Unterzustand Migrating Data, über, in dem das Klonen/Kopieren der Datenbanken durchgeführt werden.
• Für jede zu migrierende Datenbank gibt es einen eigenen Abschnitt mit sämtlichen Migrationsdetails, z. B. Anzahl der Tabellen, inkrementelle Einfügungen, Löschungen und ausstehende Bytes.
• Die zur Beendigung des Unterzustands Migrating Data benötigte Zeit hängt von der Größe der Datenbanken ab, die migriert werden.
• Die Migration geht in den Zustand Succeeded über, sobald der Unterzustand Migrating Data erfolgreich beendet wurde. Wenn im Unterzustand Migrating Data ein Problem auftritt, geht die Migration in den Zustand Failed über.

Einrichten der Replikation

Wenn die Vorschau für die Onlinemigrationen ausgewählt ist, muss die logische Replikation auf dem Single-Quellserver aktiviert sein. Wenn sie nicht aktiviert ist, aktiviert der Migrationsdienst automatisch die logische Replikation auf dem einzelnen Quellserver, wenn der Parameter SetupLogicalReplicationOnSourceDBIfNeeded mit einem Wert von true in der zugehörigen JSON-Datei übergeben wird. Die Replikation kann auch manuell an der Quelle nach dem Starten der Migration mithilfe des folgenden Befehls eingerichtet werden. Bei beiden Methoden zur Aktivierung der logischen Replikation wird der einzelne Quellserver neu gestartet.

Zum Beispiel:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Dieser Befehl ist erforderlich, um die Migration voranzutreiben, wenn der flexible Server im WaitingForLogicalReplicationSetupRequestOnSourceDB Zustand wartet.

Um die Onlinemigration in einer der oben genannten Regionen durchzuführen, verwenden Sie:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode online

Auflisten der Migrationen

Mit dem Befehl list können Sie die erfolgten Migrationsversuche zu einem Flexible Server-Ziel auflisten:

az postgres flexible-server migration list [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--filter]

Der Parameter filter verfügt über zwei Optionen:

• Active: Listet die derzeit aktiven Migrationsversuche (in Bearbeitung) für den Zielserver auf. Sie enthält nicht die Migrationen, die fehlgeschlagen sind, abgebrochen wurden oder erfolgreich waren.
• All: Listet alle Migrationsversuche zum Zielserver auf. Dies schließt sowohl die aktiven als auch frühere Migrationen ein, unabhängig von ihrem Zustand.

Weitere Informationen zu diesem Befehl erhalten Sie über den Parameter help:

az postgres flexible-server migration list -- help

Überwachen der Migration

Der Befehl show hilft Ihnen bei der Überwachung laufender Migrationen und gibt den aktuellen Zustand und Unterzustand der Migration an. Dies umfasst Informationen zum aktuellen Zustand und Unterzustand der Migration.

az postgres flexible-server migration show [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Der Parameter migration_name gibt den Namen an, der der Migration mit dem Befehl create zugewiesen wurde. Hier sehen Sie einen Screenshot der Beispielantwort des CLI-Befehls zum Anzeigen von Details:

Weitere Informationen zu diesem Befehl erhalten Sie über den Parameter help:

 az postgres flexible-server migration show -- help

In den folgenden Tabellen werden die Migrationszustände und Unterzustände beschrieben.

Migrationszustand	BESCHREIBUNG
InProgress	Die Migrationsinfrastruktur wird gerade eingerichtet, oder die tatsächliche Datenmigration wird ausgeführt.
Canceled	Die Migration wurde abgebrochen oder gelöscht.
Failed	Bei der Migration ist ein Fehler aufgetreten.
Succeeded	Die Migration wurde erfolgreich durchgeführt und ist beendet.

Migrationsunterzustand	BESCHREIBUNG
PerformingPreRequisiteSteps	Die Infrastruktur wird eingerichtet und für die Datenmigration vorbereitet.
MigratingData	Die Datenmigration wird durchgeführt.
CompletingMigration	Cutover der Migration wird ausgeführt.
Completed	die Übernahme war erfolgreich, und die Migration ist abgeschlossen.

Übernahme der Migration

Bei Onlinemigrationen wird nach Abschluss der Basisdatenmigration die Migrationsaufgabe in WaitingForCutoverTrigger den Unterstatus verschoben. In diesem Zustand kann der Benutzer die Übernahme über CLI mithilfe des folgenden Befehls auslösen. Der Übernahme kann auch über das Portal ausgelöst werden, indem der Migrationsname im Migrationsraster ausgewählt wird.

Beispiel:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --cutover

Vor dem Initiieren der Übernahme ist es wichtig, Folgendes zu gewährleisten:

• Schreibvorgänge in die Quelle werden beendet –latency Der Parameter wird auf 0 oder nahe 0 reduziert.

latency Der Parameter gibt an, wann das Ziel zuletzt mit der Quelle synchronisiert wurde. Hier ist es beispielsweise 201 und 202 für die beiden Datenbanken, wie in der Abbildung unten dargestellt. Dies bedeutet, dass die Änderungen, die in den letzten ~200 Sekunden an der Quelle aufgetreten sind, noch mit dem Ziel synchronisiert werden. Zu diesem Zeitpunkt können Schreibvorgänge an die Quelle beendet und der Übernahmevorgang initiiert werden. Falls es einen starken Datenverkehr an der Quelle gibt, empfiehlt es sich, die Schreibvorgänge zuerst zu beenden, damit Latency sich 0 nähert und dann die Übernahme initiiert wird. Der Übernahmevorgang wendet alle ausstehenden Änderungen von der Quelle auf das Ziel an und schließt die Migration ab. Wenn Sie eine „Übernahme“ auslösen, auch wenn Latency nicht Null ist, wird die Replikation bis zu diesem Zeitpunkt angehalten. Alle Quelldaten, bis der Übernahmepunkt dann auf das Ziel angewendet wird. Angenommen, die Latenzzeit zum Zeitpunkt der Übernahme betrug 15 Minuten, dann werden alle Änderungsdaten der letzten 15 Minuten auf das Ziel angewendet. Die benötigte Zeit hängt vom Backlog der Änderungen in den letzten 15 Minuten ab. Daher wird empfohlen, dass die Latenz auf Null oder nahe Null geht, bevor die Übernahme ausgelöst wird. Die latency Informationen können mithilfe des Befehls Migrationspräsentation abgerufen werden. Hier ist eine Momentaufnahme der Migration vor dem Initiieren der Übernahme:

Nach dem Initiieren des Übernahmevorgangs werden alle Transaktionen, die während der Basiskopie stattgefunden haben, sequenziell in das Ziel kopiert und die Migration wird abgeschlossen.

Wenn die Übernahme nicht erfolgreich ist, wechselt die Migration in den Zustand Failed.

Weitere Informationen zu diesem Befehl erhalten Sie über den Parameter help:

 az postgres flexible-server migration update -- help

Abbrechen der Migration mit der CLI

Sie können alle laufenden Migrationsversuche mit dem Befehl cancel abbrechen. Dieser Befehl beendet den jeweiligen Migrationsversuch, löscht jedoch keine Änderungen auf Ihrem Zielserver und führt auch kein Rollback aus. Der CLI-Befehl zum Löschen einer Migration lautet folgendermaßen:

az postgres flexible-server migration update cancel [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Beispiel:

az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1"

Weitere Informationen zu diesem Befehl erhalten Sie über den Parameter help:

 az postgres flexible-server migration update cancel -- help

Der Befehl liefert die folgende Ausgabe:

Nach der Migration

Nach Abschluss der Datenbanken müssen Sie die Daten zwischen Quelle und Ziel manuell validieren und überprüfen, ob alle Objekte in der Zieldatenbank erfolgreich erstellt wurden.

Nach der Migration können Sie die folgenden Aufgaben ausführen:

• Überprüfen Sie die Daten auf Ihrem flexiblen Server, und stellen Sie sicher, dass es sich um eine genaue Kopie der Quellinstanz handelt.

• Nach der Überprüfung aktivieren Sie die Option für Hochverfügbarkeit auf Ihrem flexiblen Server nach Bedarf.

• Ändern Sie die SKU des flexiblen Servers entsprechend den Anwendungsanforderungen. Diese Änderung erfordert einen Neustart des Datenbankservers.

• Wenn Sie Serverparameter gegenüber ihren Standardwerten in der Quellinstanz ändern, kopieren Sie diese Serverparameterwerte auf den flexiblen Server.

• Kopieren Sie andere Servereinstellungen wie Tags, Warnungen und Firewallregeln (falls zutreffend) von der Quellinstanz auf den flexiblen Server.

• Nehmen Sie Änderungen an Ihrer Anwendung vor, um die Verbindungszeichenfolgen auf einen flexiblen Server zu verweisen.

• Überwachen Sie die Datenbankleistung genau, um festzustellen, ob Leistungsoptimierung erforderlich ist.

Zugehöriger Inhalt

• Migrationsdienst
• Migrieren von AWS RDS
• bewährten Methoden
• Bekannte Probleme und Einschränkungen
• Netzwerkeinrichtung
• Validierungen vor der Migration