Freigeben über

Tutorial: Durchführen einer Onlinemigration von einem virtuellen Azure-Computer oder von einem lokalen PostgreSQL-Server zu Azure Database for PostgreSQL mithilfe des Migrationsdiensts (Vorschau)

  • Artikel

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

In diesem Artikel erfahren Sie, wie Sie eine PostgreSQL-Instanz über das Azure-Portal und die Azure CLI von Ihren lokalen virtuellen Computern (Virtual Machines, VMs) oder von Ihren virtuellen Azure-Computern zu Azure Database for PostgreSQL – Flexibler Server migrieren.

Der Migrationsdienst in Azure Database for PostgreSQL ist ein vollständig verwalteter Dienst, der in das Azure-Portal und in Azure CLI integriert ist. Der Artikel vereinfacht die Migration zu Azure Database for PostgreSQL – Flexibler Server.

  • Konfigurieren Ihrer Instanz des flexiblen Azure Database for PostgreSQL-Servers
  • Konfigurieren der Migrationsaufgabe
  • Überwachen der Migration
  • Überprüfen der abgeschlossenen Migration

Voraussetzungen

Um mit der Migration beginnen zu können, müssen die folgenden Voraussetzungen erfüllt sein:

Für die Migration mit dem Migrationsdienst von Azure Database for PostgreSQL müssen die folgenden, speziell für Onlinemigrationsszenarien geltenden Voraussetzungen erfüllt sein:

Überprüfen der Quellversion

Die Version des PostgreSQL-Quellservers muss mindestens 9.5 sein.

Sollte die PostgreSQL-Quellversion niedriger als 9.5 sein, führen Sie ein Upgrade auf 9.5 oder auf eine höhere Version durch, bevor Sie mit der Migration beginnen.

Installieren von „test_decoding“ (Quellensetup)

  • test_decoding empfängt WAL über den logischen Decodierungsmechanismus und decodiert die Daten in Textdarstellungen der ausgeführten Vorgänge.

  • Weitere Informationen zum Plug-In „test_decoding“ finden Sie in der PostgreSQL-Dokumentation.

Konfigurieren des Zielsetups

Aktivieren von CDC als Quelle

  • Das Plug-In test_decoding für die logische Decodierung erfasst die geänderten Datensätze aus der Quelle.
  • Legen Sie in der PostgreSQL-Quellinstanz die folgenden Parameter und Werte in der Konfigurationsdatei „postgresql.conf“ fest:
    • Set wal_level = logical
    • Set max_replication_slots auf einen Wert größer als 1. Der Wert muss größer sein als die Anzahl von Datenbanken, die für die Migration ausgewählt wurden.
    • Set max_wal_senders auf einen Wert größer als 1. Der Wert muss mindestens dem Wert von „max_replication_slots“ plus der Anzahl von Absendern entsprechen, die bereits von Ihrer Instanz verwendet werden.
    • Der Parameter wal_sender_timeout beendet Replikationsverbindungen, die länger als die angegebene Anzahl von Millisekunden inaktiv sind. Der Standardwert für eine lokale PostgreSQL-Datenbank beträgt 60.000 Millisekunden (60 Sekunden). Wenn Sie den Wert auf null festlegen, wird der Timeoutmechanismus deaktiviert. Dies ist eine gültige Einstellung für die Migration.

Um zu verhindern, dass die Onlinemigration nicht mehr genügend Speicherplatz 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.

Konfigurieren des Netzwerksetups

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.

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

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.

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 von Serverparametern

  • Die Serverparameterwerte für Azure Database for PostgreSQL – Flexibler Server müssen basierend auf den in der Quelle konfigurierten Serverparameterwerten manuell konfiguriert werden.

Überprüfen von Benutzern und Rollen

  • Die Benutzer und die verschiedenen Rollen müssen manuell zu Azure Database for PostgreSQL – Flexibler Server migriert werden. Benutzer und Rollen können mithilfe von pg_dumpall --globals-only -U <<username> -f <<filename>>.sql migriert werden.
  • Azure Database for PostgreSQL – Flexibler Server unterstützt keine Superuser. Benutzer mit Superuser-Rolle müssen vor der Migration entfernt werden.

Durchführen der Migration

Für die Migration kann das Azure-Portal oder die Azure-Befehlszeilenschnittstelle (Command Line Interface, CLI) verwendet werden.

In diesem Artikel erfahren Sie, wie Sie das Azure-Portal verwenden, um Ihre PostgreSQL-Datenbank von einem virtuellen Azure-Computer oder von einem lokalen PostgreSQL-Server zu einer Azure Database for PostgreSQL-Instanz zu migrieren. Über das Azure-Portal können verschiedene Aufgaben ausgeführt werden, einschließlich einer Datenbankmigration. Mithilfe der in diesem Tutorial beschriebenen Schritte können Sie Ihre Datenbank nahtlos in Azure übertragen und von den leistungsstarken Features und der Skalierbarkeit von Azure profitieren.

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 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 des flexiblen Servers im linken Menü nach unten zu „Migration“, und wählen Sie diese Option aus.

    Screenshot: Migrationsauswahlseite im Azure-Portal

  4. Wählen Sie die Schaltfläche Erstellen aus, um von einem virtuellen Azure-Computer (Virtual Machine, VM) oder von einem lokalen PostgreSQL-Server zum flexiblen Server zu migrieren. Wenn Sie den Migrationsdienst zum ersten Mal verwenden, erscheint ein leeres Raster mit einer Eingabeaufforderung, um mit Ihrer ersten Migration zu beginnen.

    Screenshot: Erstellen der Migration

    Wenn Sie bereits Migrationen zu Ihrem Ziel vom Typ „Flexibler Server“ erstellt haben, enthält das Raster Informationen zu Migrationsversuchen.

  5. Wählen Sie die Schaltfläche Erstellen. Anschließend durchlaufen Sie mehrere assistentenbasierte Registerkarten, um eine Migration vom PostgreSQL-Quellserver zu diesem Ziel vom Typ „Flexibler Server“ zu erstellen.

Setup

Die erste Registerkarte ist die Setupregisterkarte. Hier werden Migrationsdetails wie Migrationsname und Quelltyp angegeben, um die Migration zu initiieren.

Screenshot: Einrichten der Migration

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

  • Quellservertyp: Abhängig von Ihrer PostgreSQL-Quelle können Sie Azure-VM oder Lokaler Server auswählen.

  • Migrationsoption – Ermöglicht es Ihnen, Validierungen durchzuführen, bevor Sie eine Migration auslösen. Folgenden Optionen stehen zur Auswahl:

    • Ü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 vorhanden sind.

Das Auswählen der Option Überprüfen oder Überprüfen und migrieren ist eine bewährte Methode, wenn Überprüfungen vor der Migration durchgeführt werden. Weitere Informationen zur Überprüfung vor der Migration finden Sie in dieser Dokumentation.

Im Migrationsmodus können Sie den Modus für die Migration auswählen. Offline ist die Standardoption.

Wählen Sie die Schaltfläche Weiter: Mit Quelle verbinden 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.

Screenshot: Seite des Runtimeservers für die Migration

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

Herstellen einer Verbindung mit der Quelle

Auf der Registerkarte Mit Quelle verbinden werden Sie aufgefordert, Details zu der Quelle anzugeben, die auf der Registerkarte Setup ausgewählt wurde und als Quelle der Datenbanken fungiert.

Screenshot: Herstellen der Verbindung für die Quelle der Migration

  • Servername – Geben Sie den Hostnamen oder die IP-Adresse der PostgreSQL-Quellinstanz an
  • Port – Portnummer des Quellservers
  • Anmeldename des Serveradministrators – Benutzername des PostgreSQL-Quellservers
  • Kennwort – Kennwort des PostgreSQL-Quellservers
  • SSL-Modus – Unterstützte Werte werden bevorzugt und sind erforderlich. Wenn SSL auf dem PostgreSQL-Quellserver DEAKTIVIERT ist, verwenden Sie SSLMODE=prefer. Wenn SSL auf dem Quellserver AKTIVIERT ist, verwenden Sie SSLMODE=require. SSL-Werte können in der Datei postgresql.conf bestimmt werden.
  • Verbindung testen – Führt den Verbindungstest zwischen Ziel und Quelle durch. Sobald die Verbindung erfolgreich hergestellt ist, können Benutzer*innen mit dem nächsten Schritt fortfahren. Andernfalls müssen die Netzwerkprobleme zwischen dem Ziel und der Quelle identifiziert und der Benutzername bzw. das Kennwort für die Quelle überprüft werden. „Verbindung testen“ benötigt einige Minuten, um eine Verbindung zwischen Ziel und Quelle herzustellen

Wählen Sie nach dem erfolgreichen Testen der Verbindung die Schaltfläche Weiter: Migrationsziel auswählen aus.

Auswählen des Migrationsziels

Auf der Registerkarte Migrationsziel auswählen werden Metadaten für das Ziel vom Typ „Flexibler Server“ angezeigt, z. B. Abonnementname, Ressourcengruppe, Servername, Standort und PostgreSQL-Version.

Screenshot: Herstellen der Verbindung für das Ziel der Migration

  • Administratorbenutzername – Administratorbenutzername des PostgreSQL-Zielservers
  • Kennwort – Kennwort des PostgreSQL-Zielservers
  • FQDN/IP-Adresse (benutzerdefiniert): Die Angabe in diesem Feld 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.
  • Verbindung testen – Führt den Verbindungstest zwischen Ziel und Quelle durch. Sobald die Verbindung erfolgreich hergestellt ist, können Benutzer*innen mit dem nächsten Schritt fortfahren. Andernfalls müssen wir die Netzwerkprobleme zwischen dem Ziel und der Quelle identifizieren und den Benutzernamen/das Kennwort für das Ziel überprüfen. Es dauert ein paar Minuten, bis eine Testverbindung zwischen Ziel und Quelle hergestellt wurde.

Wählen Sie nach dem erfolgreichen Test der Verbindung die Option Weiter: Datenbank(en) für die Migration auswählen aus

Auswählen von Datenbanken für die Migration

Auf dieser Registerkarte befindet sich eine Liste der Benutzerdatenbanken innerhalb des Quellservers, der auf der Registerkarte „Setup“ ausgewählt wurde. 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.

Screenshot: Abrufen der Datenbank für die Migration

Wählen Sie nach dem Auswählen der Datenbanken die Schaltfläche Weiter: Zusammenfassung aus.

Zusammenfassung

Auf der Registerkarte Zusammenfassung werden alle Quell- und Zieldetails zum Erstellen der Validierung oder Migration zusammengefasst. Überprüfen Sie die Details, und wählen Sie die Schaltfläche „Starten“ aus.

Screenshot: Zusammenfassung der Migration

Überwachen der Migration

Einige Sekunden nach dem Auswählen der Schaltfläche „Starten“ wird eine Benachrichtigung mit dem Hinweis angezeigt, dass die Erstellung der Überprüfung oder Migration erfolgreich war. Sie werden automatisch zum Blatt Migration des flexiblen Servers umgeleitet, das nun einen neuen Eintrag für die kürzlich erstellte Überprüfung oder Migration enthält.

Screenshot: Überwachen der Migration im Azure-Portal

Das Raster mit den Migrationen umfasst folgende Spalten: Name, Status, Migrationsmodus, Migrationstyp, Quellserver, Quellservertyp, Datenbanken, **Dauer** und Startzeit. Die Einträge werden in absteigender Reihenfolge nach Startzeit angezeigt. Der neueste Eintrag befindet sich also am Anfang der Liste. Sie können die Schaltfläche zum Aktualisieren verwenden, um den Status der Überprüfung oder Migration zu aktualisieren. Wählen Sie den Migrationsnamen im Raster aus, 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. Die Einrichtung der Migrationsinfrastruktur und der Netzwerkverbindungen dauert zwei bis drei Minuten.

Details zur Migration

Auf der Registerkarte „Setup“ haben wir die Migrationsoption Überprüfen und migrieren ausgewählt. In diesem Szenario werden Validierungen als erstes ausgeführt, bevor die Migration startet. 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 Überprüfung ohne Fehler abgeschlossen wird, beginnt die Migration, und der Zustand des Workflows ändert sich in den Unterzustand Daten werden migriert.

Die Ergebnisse der Überprüfung werden auf der Registerkarte Überprüfung angezeigt, und die Migration wird auf der Registerkarte Migration überwacht.

Screenshot: Details der Migration

Hier finden Sie einige mögliche Migrationszustände:

Migrationsstatus

State Beschreibung
InProgress Die Migrationsinfrastruktur wird gerade eingerichtet, oder die eigentliche Datenmigration wird gerade durchgeführt.
Canceled Die Migration wurde abgebrochen oder gelöscht.
Fehlgeschlagen Bei der Migration ist ein Fehler aufgetreten.
Überprüfung fehlgeschlagen Die Überprüfung war nicht erfolgreich.
Erfolgreich Die Migration wurde erfolgreich durchgeführt und ist beendet.
WaitingForUserAction Gilt nur für die Onlinemigration. Warten auf Benutzeraktion zum Ausführen des Cutover.

Migrationsunterzustände

Unterzustand Beschreibung
PerformingPreRequisiteSteps Die Infrastruktur für die Datenmigration wird gerade eingerichtet.
Überprüfung wird ausgeführt Die Überprüfung wird ausgeführt.
MigratingData Die Datenmigration wird durchgeführt.
CompletingMigration Die Migration ist fast abgeschlossen.
Abgeschlossen Die Migration wurde abgeschlossen.
Fehler Die Migration ist fehlgeschlagen.

Unterzustände der Überprüfung

Unterzustand Beschreibung
Fehler Fehler bei der Überprüfung.
Erfolgreich Die Überprüfung war erfolgreich.
Warning Die Überprüfung befindet sich im Zustand „Warnung“.

Übernahme

Bei Migrieren und Überprüfen und migrieren ist noch ein weiterer Schritt erforderlich, um die Onlinemigration abzuschließen: Der Benutzer muss eine Cutover-Aktion ausführen. 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 den Cutover auslösen, indem er im Portal die Migration auswählt.

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

  • Schreibvorgänge in die Quelle werden beendet. Der Wert Latency ist 0 oder fast 0. Die Latency-Information kann über den Bildschirm mit den Migrationsdetails ermittelt werden:
  • Der Wert latency sinkt auf 0 oder auf einen Wert nahe 0.
  • Der Wert latency gibt an, wann das Ziel zuletzt mit der Quelle synchronisiert wurde. An diesem Punkt kann das Schreiben in die Quelle beendet und ein Cutover 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 einen Cutover auslösen, wird die Replikation bis zu diesem Zeitpunkt angehalten, auch wenn Latency, nicht null ist. Alle Quelldaten, bis der Übernahmepunkt dann auf das Ziel angewendet wird. Bei einer Wartezeit von 15 Minuten zum Zeitpunkt des Cutovers werden alle geänderten Daten der letzten 15 Minuten auf das Ziel angewendet. Die Zeit hängt vom Rückstand der Änderungen in den letzten 15 Minuten ab. Daher empfiehlt es sich, mit dem Auslösen des Cutovers zu warten, bis die Wartezeit null oder nahezu null ist.

  • Der Zustand der Migration ändert sich in Succeeded, wenn der Unterzustand Migrating Data oder der Cutover (bei der Onlinemigration) erfolgreich abgeschlossen wurde. Wenn im Unterzustand Migrating Data ein Problem auftritt, geht die Migration in den Zustand Failed über.

Abbrechen der Migration

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

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. Löschen Sie unbedingt die Datenbanken auf Ihrem Zielserver, wenn dieser an einer abgebrochenen Migration beteiligt war.

Überprüfen der abgeschlossenen 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 weitere Servereinstellungen wie Tags, Warnungen und Firewallregeln (falls zutreffend) aus 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