Tutorial: Migrieren von Azure DB for PostgreSQL – Einzelserver zu Flexibler Server mit dem Migrationsdienst

GILT FÜR: Azure Database for PostgreSQL – Flexibler 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 beginnen, müssen Sie die folgenden Voraussetzungen erfüllen, die für Offlinemigrationsszenarios 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 Flexible Server muss in Azure bereitgestellt und ordnungsgemäß konfiguriert werden, bevor Sie mit dem Migrationsprozess beginnen.

• 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 Netzwerksetup ist entscheidend, damit der Migrationsdienst ordnungsgemäß funktioniert. Stellen Sie sicher, dass der PostgreSQL-Quellserver mit dem Azure Database for PostgreSQL-Zielserver kommunizieren kann. Die folgenden Netzwerkkonfigurationen sind für eine erfolgreiche Migration unerlässlich.

Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst.

Aktivieren von Erweiterungen

Um eine erfolgreiche Migration mit dem Migrationsdienst in Azure Database for PostgreSQL sicherzustellen, müssen Sie möglicherweise Erweiterungen für Ihre PostgreSQL-Quellinstanz überprüfen. Erweiterungen bieten Funktionalität und Features, die für Ihre Anwendung möglicherweise erforderlich sind. Überprüfen Sie die Erweiterungen unbedingt in der PostgreSQL-Quellinstanz, bevor Sie den Migrationsprozess initiieren.

Aktivieren Sie in der Zielinstanz von Azure Database for PostgreSQL – Flexibler Server unterstützte Erweiterungen, die in der PostgreSQL-Quellinstanz identifiziert werden.

Weitere Informationen finden Sie unter Erweiterungen in Azure Database for PostgreSQL.

Hinweis

Bei Änderungen am shared_preload_libraries-Parameter ist ein Neustart erforderlich.

Überprüfen der 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 Instanz von Azure Database for PostgreSQL ab, indem Sie im Azure-Portal auf den Abschnitt Serverparameter zugreifen und die Werte manuell entsprechend anpassen.

• Speichern Sie die Parameteränderungen, und starten Sie gegebenenfalls die Instanz von Azure Database for PostgreSQL Flexible Server neu, damit die neue Konfiguration angewendet wird.

Wichtig

Ändern Sie den password_encryption Serverparameter auf dem flexiblen Server von SCRAM-SHA-256 in MD5, bevor Sie die Migration initiieren. Dies ist für die vorhandenen Anmeldeinformationen auf einem einzelnen Server unerlässlich, um auf Ihrem flexiblen Server zu arbeiten.

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

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

• Sie können einen reibungslosen Migrationsprozess ohne die hinzugefügten Variablen sicherstellen, die durch „Hochverfügbarkeit“ und „Lesereplikate“ eingeführt wurden, indem Sie diese Richtlinien befolgen. 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 von Azure Database for PostgreSQL – Flexibler Server

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

• Setzen Sie die Erweiterungen auf die 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. Ist dies der Fall, ist die Migration möglicherweise langsamer als erwartet. 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. Sie durchlaufen eine assistentenbasierte Reihe von Registerkarten, um eine Migration aus verschiedenen möglichen Quellen in diese Flexible Server-Zielinstanz zu erstellen. Standardmäßig ist der Quellservertyp auf Azure Database for PostgreSQL Single Server festgelegt. Hierbei handelt es sich um den Typ, der für dieses Szenario relevant ist.

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 eine Flexible Server-Instanz erstellt haben und diese als Ziel verwenden möchten, wählen Sie Vorhandene auswählen und anschließend die entsprechenden Details für Abonnement, Ressourcengruppe und Servername aus. Nachdem die Auswahl getroffen wurde, wählen Sie Zum Migrations-Assistenten wechseln aus, und folgen Sie den Anweisungen im Abschnitt Setup.

   

4. Wenn Sie eine neue Flexible Server-Instanz erstellen möchten, wählen Sie Neu erstellen und 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.

Setup

Die erste Registerkarte ist Einrichtung. Falls Sie den Schritt übersehen haben, setzen Sie erforderliche Erweiterungen auf die Positivliste, wie im Abschnitt Konfigurieren Ihrer Instanz von Azure Database for PostgreSQL Flexible Server beschrieben wird, bevor Sie eine Migration initiieren.

Beim Migrationsnamen handelt es sich um den eindeutigen Bezeichner für eine Migration zu diesem Flexible Server-Ziel. Dieses Feld akzeptiert ausschließlich alphanumerische Zeichen und keine Sonderzeichen außer Unterstrichen (_) und Bindestrichen (-). Der Name muss mit einem alphanumerischen Zeichen beginnen. Der Name muss auch für einen Zielserver eindeutig sein, da zwei Migrationen zur selben Flexible Server-Zielinstanz nicht denselben Namen aufweisen dürfen.

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 Validierungen 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.

Migrationsmodus: Erlaubt es Ihnen, zwischen einer Online- und einer Offlinemigration wählen. In diesem Fall muss der Modus auf Offline festgelegt werden.

Wählen Sie die Schaltfläche Weiter: Runtimeserver auswählen aus.

Runtimeserver

Der Runtimeserver für die Migration ist ein spezielles Feature im Migrationsdienst in Azure Database for PostgreSQL, das während der Migration als Zwischenserver fungiert. Es handelt sich um eine separate Instanz von Azure Database for PostgreSQL – Flexibler Server, die nicht als Zielserver fungiert, sondern verwendet wird, um die Migration von Datenbanken aus einer Quellumgebung zu ermöglichen, auf die nur über ein privates Netzwerk zugegriffen werden kann.

Weitere Informationen zum Runtimeserver finden Sie im Artikel zum Runtimeserver für die Migration.

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

Herstellen einer Verbindung mit der Quelle

Im Abschnitt Quelle werden Sie dazu aufgefordert, Details zu der Single Server-Instanz anzugeben, die die Quelle der Datenbanken darstellt.

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.

Nachdem Sie die Single Server-Quellinstanz ausgewählt haben, werden die Felder Standort und PostgreSQL-Version automatisch ausgefüllt. Stellen Sie sicher, dass Sie die Anmeldeinformationen einer Administratorrolle angeben, da diese erforderlich sind, damit der Migrationsdienst die Datenbanken erfolgreich migrieren kann.

Das Feld FQDN/IP-Adresse (benutzerdefiniert) ist optional und kann verwendet werden, wenn sich die Quelle hinter einem benutzerdefinierten DNS-Server befindet oder über benutzerdefinierte DNS-Namespaces verfügt, sodass nur über bestimmte FQDNs oder IP-Adressen auf die Quelle zugegriffen werden kann. Hierbei kann es sich beispielsweise um Einträge wie singleserver.example.com, 198.1.0.2 oder um einen PostgreSQL-FQDN wie singleserver.postgres.database.azure.com handeln, wenn der benutzerdefinierte DNS-Server die DNS-Zone postgres.database.azure.com enthält oder Abfragen für diese Zone an 168.63.129.16 weiterleitet, wobei der FQDN in der öffentlichen oder privaten DNS-Zone von Azure aufgelöst wird.

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.

Auswählen des Migrationsziels

Im Abschnitt Migrationsziel auswählen werden Metadaten für die Flexible Server-Zielinstanz wie Abonnement, Ressourcengruppe, Servername, Standort und PostgreSQL-Version angezeigt.

Das Feld FQDN/IP-Adresse (benutzerdefiniert) ist optional und kann verwendet werden, wenn sich das Ziel hinter einem benutzerdefinierten DNS-Server befindet oder über benutzerdefinierte DNS-Namespaces verfügt, sodass nur über bestimmte FQDNs oder IP-Adressen darauf zugegriffen werden kann. Hierbei kann es sich beispielsweise um Einträge wie flexibleserver.example.com, 198.1.0.2 oder um einen PostgreSQL-FQDN wie flexibleserver.postgres.database.azure.com handeln, wenn der benutzerdefinierte DNS-Server die DNS-Zone postgres.database.azure.com enthält oder Abfragen für diese Zone an 168.63.129.16 weiterleitet, wobei der FQDN in der öffentlichen oder privaten DNS-Zone von Azure aufgelöst wird.

Wählen Sie die geeigneten Werte für Authentifizierungsmethode sowie alle Felder im Zusammenhang mit der Authentifizierung aus. Stellen Sie sicher, dass die bereitgestellte Identität die Identität des Administratorbenutzers auf dem Zielserver ist. Wählen Sie nach dem Ausfüllen aller erforderlichen Informationen den Link Verbindung mit Ziel herstellen aus. Dadurch wird überprüft, ob die eingegebenen Zielserverdetails korrekt sind und der Zielserver erreichbar ist.

Wählen Sie die Schaltfläche Weiter: Datenbanken für die Migration auswählen aus, um die zu migrierenden Datenbanken auszuwählen.

Auswählen von Datenbanken für die 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. Ausgewählte Datenbanken, die auf dem Zielserver mit genau demselben Namen vorhanden sind, werden überschrieben.

Wählen Sie die Schaltfläche Weiter: Zusammenfassung 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 Validierung und Migration starten aus.

Überwachen des Migrationsportals

Nachdem Sie die Migration gestartet haben, wird eine Benachrichtigung angezeigt, dass die Validierung oder Migrationserstellung erfolgreich ist. 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, Migrationsmodus, Migrationstyp, 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 Aktualisieren verwenden, um den Status der Validierung oder Migration zu aktualisieren.

Sie können im Raster außerdem den Namen einer bestimmten Migration auswählen, um die zugehörigen 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.

Im folgenden Abschnitt wird veranschaulicht, 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 folgenden Informationen:

• 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.
• Validierungsname: Der Name jeder bestimmten Gültigkeitsprüfungsregel
• Validierungsstatus: Stellt das Ergebnis für die einzelnen Regeln dar und kann einen der drei Werte aufweisen:
  • Erfolgreich, wenn keine Fehler gefunden wurden
  • Fehler, wenn Überprüfungsfehler vorliegen
  • Warnung, wenn Überprüfungswarnungen vorliegen
• Dauer: Zeitaufwand für den Validierungsvorgang
• Startzeit (UTC) und Endzeit (UTC): Start- und Endzeiten 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 Unterstatus PerformingPreRequisiteSteps abgeschlossen wurde, wechselt die Migration in den Unterstatus Daten werden migriert, 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 enthält die Anzahl aller Tabellen („Kopiert“, „In Warteschlange“, „Wird kopiert“ und „Fehler“) sowie den 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 Seite aktualisieren, um den Fortschritt zu überprüfen.

Ü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

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.

Um zu verhindern, dass die Onlinemigration nicht mehr genügend Speicherplatz zum Speichern der Protokolle hat, stellen Sie sicher, dass Sie über ausreichend Speicherplatz im Tabellenbereich auf einem bereitgestellten verwalteten Datenträger verfügen. Deaktivieren Sie dazu den Serverparameter azure.enable_temp_tablespaces_on_local_ssd auf dem flexiblen Server für die Dauer der Migration, und setzen Sie ihn nach der Migration wieder in den ursprünglichen Zustand zurück.

Einrichten des Ziels

• 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;

Wichtig

Ändern Sie den password_encryption Serverparameter auf dem flexiblen Server von SCRAM-SHA-256 in MD5, bevor Sie die Migration initiieren. Dies ist für die vorhandenen Anmeldeinformationen auf einem einzelnen Server unerlässlich, um auf Ihrem flexiblen Server zu arbeiten.

Einrichten des Netzwerks

Das Netzwerksetup ist entscheidend, damit der Migrationsdienst ordnungsgemäß funktioniert. Stellen Sie sicher, dass der PostgreSQL-Quellserver mit dem Azure Database for PostgreSQL-Zielserver kommunizieren kann. Die folgenden Netzwerkkonfigurationen sind für eine erfolgreiche Migration unerlässlich.

Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst.

Aktivieren von Erweiterungen

Um eine erfolgreiche Migration mit dem Migrationsdienst in Azure Database for PostgreSQL sicherzustellen, müssen Sie möglicherweise Erweiterungen für Ihre PostgreSQL-Quellinstanz überprüfen. Erweiterungen bieten Funktionalität und Features, die für Ihre Anwendung möglicherweise erforderlich sind. Überprüfen Sie die Erweiterungen unbedingt in der PostgreSQL-Quellinstanz, bevor Sie den Migrationsprozess initiieren.

Aktivieren Sie in der Zielinstanz von Azure Database for PostgreSQL – Flexibler Server unterstützte Erweiterungen, die in der PostgreSQL-Quellinstanz identifiziert werden.

Weitere Informationen finden Sie unter Erweiterungen in Azure Database for PostgreSQL.

Hinweis

Bei Änderungen am shared_preload_libraries-Parameter ist ein Neustart erforderlich.

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.

Hinweis

Bestimmte Einschränkungen gelten für die Onlinemigration, die hier dokumentiert sind. Stellen Sie sicher, dass Ihre Datenbank kompatibel ist, um eine Onlinemigration auszuführen.

Konfigurieren Ihrer Instanz von Azure Database for PostgreSQL – Flexibler Server

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

• Setzen Sie die Erweiterungen auf die 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. Ist dies der Fall, ist die Migration möglicherweise langsamer als erwartet. 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. Sie durchlaufen eine assistentenbasierte Reihe von Registerkarten, um eine Migration aus verschiedenen möglichen Quellen in diese Flexible Server-Zielinstanz zu erstellen. Standardmäßig ist der Quellservertyp auf Azure Database for PostgreSQL Single Server festgelegt. Hierbei handelt es sich um den Typ, der für dieses Szenario relevant ist.

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 eine Flexible Server-Instanz erstellt haben und diese als Ziel verwenden möchten, wählen Sie Vorhandene auswählen und anschließend die entsprechenden Details für Abonnement, Ressourcengruppe und Servername aus. Nachdem die Auswahl getroffen wurde, wählen Sie Zum Migrations-Assistenten wechseln aus, und folgen Sie den Anweisungen im Abschnitt Setup.

   

4. Wenn Sie eine neue Flexible Server-Instanz erstellen möchten, wählen Sie Neu erstellen und 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.

Setup

Die erste Registerkarte ist Einrichtung. Falls Sie den Schritt übersehen haben, setzen Sie erforderliche Erweiterungen auf die Positivliste, wie im Abschnitt Konfigurieren Ihrer Instanz von Azure Database for PostgreSQL Flexible Server beschrieben wird, bevor Sie eine Migration initiieren.

Beim Migrationsnamen handelt es sich um den eindeutigen Bezeichner für eine Migration zu diesem Flexible Server-Ziel. Dieses Feld akzeptiert ausschließlich alphanumerische Zeichen und keine Sonderzeichen außer Unterstrichen (_) und Bindestrichen (-). Der Name muss mit einem alphanumerischen Zeichen beginnen. Der Name muss auch für einen Zielserver eindeutig sein, da zwei Migrationen zur selben Flexible Server-Zielinstanz nicht denselben Namen aufweisen dürfen.

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 Validierungen 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.

Migrationsmodus: Erlaubt es Ihnen, zwischen einer Online- und einer Offlinemigration wählen. In diesem Fall muss dieser auf Online festgelegt werden.

Wenn der Migrationsmodus Online ausgewählt ist, muss die logische Replikation in der Single Server-Quellinstanz aktiviert sein. Wenn sie nicht aktiviert ist, aktiviert der Migrationsdienst automatisch die logische Replikation auf dem Quellserver. Die Replikation kann ebenfalls manuell eingerichtet werden, indem Sie im Ressourcenmenü der Single Server-Instanz unter Einstellungen das Element Replikation auswählen und Azure-Replikationsunterstützung auf Logisch festlegen. Bei beiden Ansätzen wird der Quellserver neu gestartet.

Wählen Sie die Schaltfläche Weiter: Runtimeserver auswählen aus.

Runtimeserver

Der Runtimeserver für die Migration ist ein spezielles Feature im Migrationsdienst in Azure Database for PostgreSQL, das während der Migration als Zwischenserver fungiert. Es handelt sich um eine separate Instanz von Azure Database for PostgreSQL – Flexibler Server, die nicht als Zielserver fungiert, sondern verwendet wird, um die Migration von Datenbanken aus einer Quellumgebung zu ermöglichen, auf die nur über ein privates Netzwerk zugegriffen werden kann.

Weitere Informationen zum Runtimeserver finden Sie im Artikel zum Runtimeserver für die Migration.

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

Herstellen einer Verbindung mit der Quelle

Im Abschnitt Quelle werden Sie dazu aufgefordert, Details zu der Single Server-Instanz anzugeben, die die Quelle der Datenbanken darstellt.

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.

Nachdem Sie die Single Server-Quellinstanz ausgewählt haben, werden die Felder Standort und PostgreSQL-Version automatisch ausgefüllt. Stellen Sie sicher, dass Sie die Anmeldeinformationen einer Administratorrolle angeben, da diese erforderlich sind, damit der Migrationsdienst die Datenbanken erfolgreich migrieren kann.

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.

Auswählen des Migrationsziels

Im Abschnitt Migrationsziel auswählen werden Metadaten für die Flexible Server-Zielinstanz wie Abonnement, Ressourcengruppe, Servername, Standort und PostgreSQL-Version angezeigt.

Wählen Sie die geeigneten Werte für Authentifizierungsmethode sowie alle Felder im Zusammenhang mit der Authentifizierung aus. Stellen Sie sicher, dass die bereitgestellte Identität die Identität des Administratorbenutzers auf dem Zielserver ist. Wählen Sie nach dem Ausfüllen aller erforderlichen Informationen den Link Verbindung mit Ziel herstellen aus. Dadurch wird überprüft, ob die eingegebenen Zielserverdetails korrekt sind und der Zielserver erreichbar ist.

Wählen Sie die Schaltfläche Weiter: Datenbanken für die Migration auswählen aus, um die zu migrierenden Datenbanken auszuwählen.

Auswählen von Datenbanken für die 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. Ausgewählte Datenbanken, die auf dem Zielserver mit genau demselben Namen vorhanden sind, werden überschrieben.

Wählen Sie die Schaltfläche Weiter: Zusammenfassung 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 Validierung und Migration starten aus.

Überwachen des Migrationsportals

Nachdem Sie die Migration gestartet haben, wird eine Benachrichtigung angezeigt, dass die Validierung oder Migrationserstellung erfolgreich ist. 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, Migrationsmodus, Migrationstyp, 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 Aktualisieren verwenden, um den Status der Validierung oder Migration zu aktualisieren.

Sie können im Raster außerdem den Namen einer bestimmten Migration auswählen, um die zugehörigen 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.

Im folgenden Abschnitt wird veranschaulicht, 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 folgenden Informationen:

• 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.
• Validierungsname: Der Name jeder bestimmten Gültigkeitsprüfungsregel
• Validierungsstatus: Stellt das Ergebnis für die einzelnen Regeln dar und kann einen der drei Werte aufweisen:
  • Erfolgreich, wenn keine Fehler gefunden wurden
  • Fehler, wenn Überprüfungsfehler vorliegen
  • Warnung, wenn Überprüfungswarnungen vorliegen
• Dauer: Zeitaufwand für den Validierungsvorgang
• Startzeit (UTC) und Endzeit (UTC): Start- und Endzeiten 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 Unterstatus PerformingPreRequisiteSteps abgeschlossen wurde, wechselt die Migration in den Unterstatus Daten werden migriert, 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 enthält die Anzahl aller Tabellen („Kopiert“, „In Warteschlange“, „Wird kopiert“ und „Fehler“) sowie den 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 Seite aktualisieren, um den Fortschritt zu überprüfen.

Ü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

Der Abschluss der Onlinemigration erfordert bei den Migrationsoptionen Migrieren und Validieren und Migrieren, dass der Benutzer einen zusätzlichen Schritt ausführt, der die Aktion „Cutover“ auslöst. Nach Abschluss des Kopierens bzw. Klonens der Basisdaten wechselt die Migration in den Status WaitingForUserAction und den Unterstatus WaitingForCutoverTrigger. In diesem Status kann der Benutzer den Cutover über das Portal auslösen, indem er die Migration und anschließend die Schaltfläche Cutover auswählt.

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

• Schreibvorgänge in die Quelle werden beendet und der Parameter -Latency (minutes) ist 0 oder nahe 0. Die Latency (minutes)-Informationen können über den Bildschirm „Migrationsdetails“ abgerufen werden:

Latency (minutes) Der Parameter gibt an, wann das Ziel zuletzt mit der Quelle synchronisiert wurde. Im Beispiel der obenstehenden Datenbank Orders beträgt dieser 0,33333. Das bedeutet, dass die Änderungen für die Datenbank Orders, die in den letzten ~0,3 Minuten an der Quelle aufgetreten sind, noch an das Ziel gesendet werden. Zu diesem Zeitpunkt können Schreibvorgänge an die Quelle beendet und der Übernahmevorgang initiiert werden. Bei starkem Datenverkehr an der Quelle wird empfohlen, die Schreibvorgänge zuerst zu beenden und erst dann den Cutover initiieren, damit Latency (minutes) nahe 0 sein kann. Der Cutovervorgang wendet alle ausstehenden Änderungen von der Quelle auf das Ziel an und schließt die Migration ab. Wenn Sie einen Cutover selbst mit Nicht-Null-Latenz auslösen, wird die Replikation bis zu diesem Zeitpunkt angehalten. Alle Quelldaten, bis der Übernahmepunkt dann auf das Ziel angewendet wird. Wenn die Latenz am Cutoverpunkt 15 Minuten beträgt, werden alle in den letzten 15 Minuten geänderten Daten 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 null oder nahe null ist, bevor der Cutover ausgelöst wird.

Die Migration wechselt in den Status Erfolgreich, sobald der Unterstatus Daten werden migriert oder im Migrationsmodus „Online“ der Cutover erfolgreich abgeschlossen ist. Wenn beim Unterstatus Daten werden migriert ein Problem auftritt, wechselt die Migration in den Status Fehlgeschlagen.

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. Die Aktion „Abbrechen“ führt ein Rollback aller Änderungen aus, die vom Migrationsdienst auf Ihrem Zielserver vorgenommen wurden.

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 beginnen, müssen Sie die folgenden Voraussetzungen erfüllen, die für Offlinemigrationsszenarios 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 Flexible Server muss in Azure bereitgestellt und ordnungsgemäß konfiguriert werden, bevor Sie mit dem Migrationsprozess beginnen.

• 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 Netzwerksetup ist entscheidend, damit der Migrationsdienst ordnungsgemäß funktioniert. Stellen Sie sicher, dass der PostgreSQL-Quellserver mit dem Azure Database for PostgreSQL-Zielserver kommunizieren kann. Die folgenden Netzwerkkonfigurationen sind für eine erfolgreiche Migration unerlässlich.

Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst.

Aktivieren von Erweiterungen

Um eine erfolgreiche Migration mit dem Migrationsdienst in Azure Database for PostgreSQL sicherzustellen, müssen Sie möglicherweise Erweiterungen für Ihre PostgreSQL-Quellinstanz überprüfen. Erweiterungen bieten Funktionalität und Features, die für Ihre Anwendung möglicherweise erforderlich sind. Überprüfen Sie die Erweiterungen unbedingt in der PostgreSQL-Quellinstanz, bevor Sie den Migrationsprozess initiieren.

Aktivieren Sie in der Zielinstanz von Azure Database for PostgreSQL – Flexibler Server unterstützte Erweiterungen, die in der PostgreSQL-Quellinstanz identifiziert werden.

Weitere Informationen finden Sie unter Erweiterungen in Azure Database for PostgreSQL.

Hinweis

Bei Änderungen am shared_preload_libraries-Parameter ist ein Neustart erforderlich.

Überprüfen der 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 Instanz von Azure Database for PostgreSQL ab, indem Sie im Azure-Portal auf den Abschnitt Serverparameter zugreifen und die Werte manuell entsprechend anpassen.

• Speichern Sie die Parameteränderungen, und starten Sie gegebenenfalls die Instanz von Azure Database for PostgreSQL Flexible Server neu, damit die neue Konfiguration angewendet wird.

Wichtig

Ändern Sie den password_encryption Serverparameter auf dem flexiblen Server von SCRAM-SHA-256 in MD5, bevor Sie die Migration initiieren. Dies ist für die vorhandenen Anmeldeinformationen auf einem einzelnen Server unerlässlich, um auf Ihrem flexiblen Server zu arbeiten.

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

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

• Sie können einen reibungslosen Migrationsprozess ohne die hinzugefügten Variablen sicherstellen, die durch „Hochverfügbarkeit“ und „Lesereplikate“ eingeführt wurden, indem Sie diese Richtlinien befolgen. 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

Beim Ausführen des vorherigen Befehls wird die folgende Ausgabe zurückgegeben:

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

Beim Ausführen des vorherigen Befehls wird die folgende Ausgabe zurückgegeben:

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 jede Migration zu dieser Flexible Server-Zielinstanz. Dieses Feld akzeptiert ausschließlich alphanumerische Zeichen und keine Sonderzeichen außer Unterstrichen (_) und Bindestrichen (-). Der Name muss mit einem alphanumerischen Zeichen beginnen und enden. Der Name muss auch für einen Zielserver eindeutig sein, da zwei Migrationen zur selben Flexible Server-Zielinstanz nicht denselben Namen aufweisen dürfen.
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 "./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/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
		"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-Quellinstanz.
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 Administratorbenutzer, der während der Erstellung einer Single Server-Instanz angegeben wurde, und das angegebene Kennwort werden für die Authentifizierung mit diesem 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 Administratorbenutzer, der während der Erstellung einer Flexible Server-Instanz erstellt wurde, und das angegebene Kennwort werden für die Authentifizierung mit diesem 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. System- 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 Status InProgress und den Unterstatus PerformingPreRequisiteSteps. Der Migrations-Workflow benötigt ein paar Minuten, um die Migrationsinfrastruktur bereitzustellen und Verbindungen zwischen der Quelle und dem Ziel einzurichten.
• Nach Abschluss des Unterstatus PerformingPreRequisiteSteps wechselt die Migration in den Unterstatus Migrating Data,, in dem die Datenbanken geklont bzw. kopiert 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.

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 aktuellen aktiven Migrationsversuche (in Arbeit) auf dem Zielserver auf. Sie enthält nicht die Migrationen, die fehlgeschlagen sind, abgebrochen wurden oder erfolgreich waren.
• All: Listet alle Migrationsversuche zum Zielserver auf. Dazu gehören unabhängig vom Status die aktiven und abgeschlossenen Migrationen.

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.

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.
ValidationFailed	Die Migration ist während der Validierung vor der Migration fehlgeschlagen.

Migrationsunterzustand	Beschreibung
PerformingPreRequisiteSteps	Die Infrastruktur wird eingerichtet und für die Datenmigration vorbereitet.
MigratingData	Die Datenmigration wird durchgeführt.
CompletingMigration	Der Migrationsprozess wird abgeschossen.
Completed	Die Migration wurde in einem erfolgreichen oder nicht erfolgreichen Status abgeschlossen.
CancelingRequestedDBMigrations	Die Migration wird abgebrochen.
ValidationInProgress	Die Überprüfung wird ausgeführt.

Online

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.

Um zu verhindern, dass die Onlinemigration nicht mehr genügend Speicherplatz zum Speichern der Protokolle hat, stellen Sie sicher, dass Sie über ausreichend Speicherplatz im Tabellenbereich auf einem bereitgestellten verwalteten Datenträger verfügen. Deaktivieren Sie dazu den Serverparameter azure.enable_temp_tablespaces_on_local_ssd auf dem flexiblen Server für die Dauer der Migration, und setzen Sie ihn nach der Migration wieder in den ursprünglichen Zustand zurück.

Einrichten des Ziels

• 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;

Wichtig

Ändern Sie den password_encryption Serverparameter auf dem flexiblen Server von SCRAM-SHA-256 in MD5, bevor Sie die Migration initiieren. Dies ist für die vorhandenen Anmeldeinformationen auf einem einzelnen Server unerlässlich, um auf Ihrem flexiblen Server zu arbeiten.

Einrichten des Netzwerks

Das Netzwerksetup ist entscheidend, damit der Migrationsdienst ordnungsgemäß funktioniert. Stellen Sie sicher, dass der PostgreSQL-Quellserver mit dem Azure Database for PostgreSQL-Zielserver kommunizieren kann. Die folgenden Netzwerkkonfigurationen sind für eine erfolgreiche Migration unerlässlich.

Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst.

Aktivieren von Erweiterungen

Um eine erfolgreiche Migration mit dem Migrationsdienst in Azure Database for PostgreSQL sicherzustellen, müssen Sie möglicherweise Erweiterungen für Ihre PostgreSQL-Quellinstanz überprüfen. Erweiterungen bieten Funktionalität und Features, die für Ihre Anwendung möglicherweise erforderlich sind. Überprüfen Sie die Erweiterungen unbedingt in der PostgreSQL-Quellinstanz, bevor Sie den Migrationsprozess initiieren.

Aktivieren Sie in der Zielinstanz von Azure Database for PostgreSQL – Flexibler Server unterstützte Erweiterungen, die in der PostgreSQL-Quellinstanz identifiziert werden.

Weitere Informationen finden Sie unter Erweiterungen in Azure Database for PostgreSQL.

Hinweis

Bei Änderungen am shared_preload_libraries-Parameter ist ein Neustart erforderlich.

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.

Hinweis

Bestimmte Einschränkungen gelten für die Onlinemigration, die hier dokumentiert sind. Stellen Sie sicher, dass Ihre Datenbank kompatibel ist, um eine Onlinemigration auszuführen.

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

Beim Ausführen des vorherigen Befehls wird die folgende Ausgabe zurückgegeben:

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

Beim Ausführen des vorherigen Befehls wird die folgende Ausgabe zurückgegeben:

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 jede Migration zu dieser Flexible Server-Zielinstanz. Dieses Feld akzeptiert ausschließlich alphanumerische Zeichen und keine Sonderzeichen außer Unterstrichen (_) und Bindestrichen (-). Der Name muss mit einem alphanumerischen Zeichen beginnen und enden. Der Name muss auch für einen Zielserver eindeutig sein, da zwei Migrationen zur selben Flexible Server-Zielinstanz nicht denselben Namen aufweisen dürfen.
migration-mode	Dies ist ein optionaler Parameter. Der Standardwert ist Offline. Für Onlinemigrationen müssen Sie Online übergeben.
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 "./migrationBody.json" --migration-mode online

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/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "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-Quellinstanz.
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 Administratorbenutzer, der während der Erstellung einer Single Server-Instanz angegeben wurde, und das angegebene Kennwort werden für die Authentifizierung mit diesem 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 Administratorbenutzer, der während der Erstellung einer Flexible Server-Instanz erstellt wurde, und das angegebene Kennwort werden für die Authentifizierung mit diesem 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. System- 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 Status InProgress und den Unterstatus PerformingPreRequisiteSteps. Der Migrations-Workflow benötigt ein paar Minuten, um die Migrationsinfrastruktur bereitzustellen und Verbindungen zwischen der Quelle und dem Ziel einzurichten.
• Nach Abschluss des Unterstatus PerformingPreRequisiteSteps wechselt die Migration in den Unterstatus Migrating Data,, in dem die Datenbanken geklont bzw. kopiert 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

Für den Migrationsmodus „Online“ muss die logische Replikation in der Single Server-Quellinstanz 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.

Verwenden Sie den folgenden Befehl, um die Onlinemigration durchzuführen:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./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 aktuellen aktiven Migrationsversuche (in Arbeit) auf dem Zielserver auf. Sie enthält nicht die Migrationen, die fehlgeschlagen sind, abgebrochen wurden oder erfolgreich waren.
• All: Listet alle Migrationsversuche zum Zielserver auf. Dazu gehören unabhängig vom Status die aktiven und abgeschlossenen Migrationen.

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

az postgres flexible-server migration list --help

Überwachen der Migrationen

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

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.
ValidationFailed	Die Migration ist während der Validierung vor der Migration fehlgeschlagen.

Migrationsunterzustand	Beschreibung
PerformingPreRequisiteSteps	Die Infrastruktur wird eingerichtet und für die Datenmigration vorbereitet.
MigratingData	Die Datenmigration wird durchgeführt.
WaitingForCutoverTrigger	Die Datenmigrationsaufgabe wurde abgeschlossen und wartet darauf, dass der Benutzer den Cutover auslöst.
CompletingMigration	Der Migrationsprozess wird abgeschossen.
Completed	Die Migration wurde in einem erfolgreichen oder nicht erfolgreichen Status abgeschlossen.
CancelingRequestedDBMigrations	Die Migration wird abgebrochen.
ValidationInProgress	Die Überprüfung wird ausgeführt.

Cutover der Migrationen

Bei Onlinemigrationen wird nach Abschluss der Basisdatenmigration die Migrationsaufgabe in den Unterstatus WaitingForCutoverTrigger 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.

Zum 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 sicherzustellen:

• Schreibvorgänge in die Quelle werden beendet und der Parameter -latency ist 0 oder nahe 0.

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 stoppt den jeweiligen Migrationsversuch und macht alle Änderungen auf Ihrem Zielserver rückgängig. Mit dem folgenden CLI-Befehl kann eine Migration abgebrochen werden:

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

Zum 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:

Überprüfen der Migration nach Abschluss des Prozesses

Stellen Sie nach einer erfolgreichen Migration sicher, dass Sie sich mit denselben Anmeldeinformationen wie auf dem einzelnen Server bei Ihrem flexiblen Server anmelden können. Wenn nach der Migration von einem einzelnen Server Authentifizierungsfehler auf Ihrem flexiblen Server auftreten, liegt dies möglicherweise daran, dass die VM des flexiblen Servers FIPS-kompatiblen oder einen anderen Kennwortverschlüsselungsalgorithmus (SCRAM-SHA-256) im Vergleich zur MD5-Verschlüsselung des einzelnen Servers verwendet. Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Ändern Sie den password_encryption Serverparameter auf dem flexiblen Server von SCRAM-SHA-256 in MD5.
2. Starten Sie die Migration von Ihrem einzelnen Server auf den flexiblen Server neu.
3. Falls Authentifizierungsprobleme weiterhin bestehen, löschen Sie den bestehenden flexiblen Server und stellen Sie einen neuen bereit. Wiederholen Sie die Schritte 1 und 2, um den Fehler zu beheben.

Dies sollte die Authentifizierungsfehler beheben.

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