Freigeben über

Bewährte Methoden für eine nahtlose Migration zu Azure Database for PostgreSQL

  • Artikel

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

In diesem Artikel werden häufige Fallstricke und bewährte Methoden erläutert, um eine reibungslose und erfolgreiche Migration zur Azure Database for PostgreSQL sicherzustellen.

Überprüfung vor der Migration

Führen Sie als ersten Migrationsschritt die Überprüfung vor der Migration aus, bevor Sie eine Migration durchführen. Sie können die Optionen Überprüfen und Überprüfen und Migrieren auf der Seite Setup der Migration verwenden. Die Überprüfung vor der Migration führt gründliche Überprüfungen anhand eines vordefinierten Regelsatzes durch. Ziel ist es, potenzielle Probleme zu identifizieren und umsetzbare Erkenntnisse zur Abhilfemaßnahmen bereitzustellen. Führen Sie die Überprüfung vor der Migration aus, bis der Status Erfolgreich lautet. Weitere Informationen finden Sie unter Validierungen vor der Migration.

Konfiguration des flexiblen Zielservers

Während der anfänglichen Basiskopie von Daten werden mehrere Einfügeanweisungen am Ziel ausgeführt, die WALs (Write Ahead Logs) generieren. Bis diese WALs archiviert worden sind, verbrauchen die Protokolle zusätzlich zu dem für die Datenbank erforderlichen Speicher Speicherplatz auf dem Ziel.

Um die Nummer zu berechnen, melden Sie sich bei der Quellinstanz an, und führen Sie diesen Befehl aus, damit alle Datenbanken migriert werden:

SELECT pg_size_pretty( pg_database_size('dbname') );

Es wird empfohlen, ausreichend Speicherplatz auf dem flexiblen Server zuzuweisen, und zwar etwa 1,25 Mal oder 25 % mehr Speicher als pro Ausgabe des obigen Befehls verbraucht wird. Sie können auch die automatische Speichervergrößerung verwenden.

Wichtig

Die Speichergröße kann bei der manuellen Konfiguration oder der automatischen Speichervergrößerung nicht reduziert werden. Jeder Schritt in der Speicherkonfiguration verdoppelt die Größe, sodass es ratsam ist, den benötigten Speicherplatz im Voraus zu schätzen.

Der Schnellstart zum Erstellen einer Instanz von Azure Database for PostgreSQL – Flexibler Server über das Portal ist ein hervorragender Ausgangspunkt. Weitere Informationen zu den einzelnen Serverkonfigurationen finden Sie unter Compute- und Speicheroptionen in Azure Database for PostgreSQL – Flexibler Server.

Wichtig

Sobald der flexible Server erstellt wurde, stellen Sie sicher, dass Sie den Serverparameter password_encryption auf Ihrem flexiblen Server von SCRAM-SHA-256 auf MD5 ändern, bevor Sie die Migration starten. Dies ist für die vorhandenen Anmeldeinformationen auf einem einzelnen Server unerlässlich, um auf Ihrem flexiblen Server zu arbeiten

Migrationszeitachse

Jede Migration hat eine maximale Lebensdauer von sieben Tagen (168 Stunden) ab ihrem Start und läuft nach dem Timeout von sieben Tagen ab. Sie können die Migration und den Anwendungscutover abschließen, nachdem die Datenvalidierung und alle Prüfungen abgeschlossen sind, um eine zeitliche Verzögerung der Migration zu vermeiden. Bei Onlinemigrationen hat das Übernahmefenster nach Abschluss der anfänglichen Basiskopie eine Dauer von drei Tagen (72 Stunden), bevor ein Timeout eintritt. Bei Offlinemigrationen sollten die Anwendungen nicht mehr in die Datenbank schreiben, damit keine Datenverluste auftreten. Ebenso sollten Sie bei einer Onlinemigration den Datenverkehr während der gesamten Migration gering halten.

Meistens werden Nicht-Produktionsserver (Entwicklung, UAT, Test und Staging) offline migriert. Da diese Server über weniger Daten als Produktionsserver verfügen, wird die Migration schnell abgeschlossen. Für die Migration von Produktionsservern müssen Sie wissen, wie viel Zeit die Migration in Anspruch nehmen würde, um sie im Voraus planen zu können.

Der für die Migration benötigte Zeitraum hängt von mehreren Faktoren ab. Hierzu gehören die Anzahl und Größe der Datenbanken, die Anzahl der Tabellen in jeder Datenbank, die Anzahl der Indizes und die Datenverteilung auf die Tabellen. Sie hängt auch von der SKU des Zielservers sowie von den auf der Quellinstanz und dem Zielserver verfügbaren IOPS ab. Angesichts der vielen Faktoren, die sich auf die Migrationszeit auswirken können, ist es schwierig, die Gesamtdauer für den Abschluss der Migration zu schätzen. Der beste Ansatz wäre die Durchführung einer Testmigration mit Ihrer Workload.

Bei der Berechnung der gesamten Downtime für die Migration eines Produktionsservers werden die folgenden Phasen berücksichtigt:

  • Migration der Zeitpunktwiederherstellung: Der beste Weg, um eine gute Schätzung der Zeit zu erhalten, die für die Migration Ihres Produktionsdatenbankservers erforderlich ist, besteht darin, eine Zeitpunktwiederherstellung (PITR) Ihres Produktionsservers durchzuführen und die Offlinemigration auf diesem neu wiederhergestellten Server auszuführen.

  • Migration des Puffers: Nach Abschluss des obigen Schritts können Sie die tatsächliche Produktionsmigration in einem Zeitraum planen, in dem der Anwendungsdatenverkehr gering ist. Diese Migration kann am selben Tag oder möglicherweise auch in einer Woche geplant werden. Bis zu diesem Zeitpunkt hat sich die Größe des Quellservers möglicherweise erhöht. Aktualisieren Sie Ihre geschätzte Migrationszeit für Ihren Produktionsserver basierend auf der Höhe dieser Zunahme. Wenn die Zunahme erheblich ist, können Sie einen weiteren Test mit dem Server für die Zeitpunktwiederherstellung (PITR) durchführen. Für die meisten Server sollte der Größenanstieg jedoch nicht signifikant genug sein.

  • Datenüberprüfung: Nachdem die Migration für den Produktionsserver abgeschlossen wurde, müssen Sie überprüfen, ob es sich bei den Daten auf dem flexiblen Server um eine genaue Kopie der Quellinstanz handelt. Sie können Open-Source- oder Drittanbietertools verwenden oder die Überprüfung manuell durchführen. Bereiten Sie die Validierungsschritte vor, die Sie vor eigentlichen Migration ausführen möchten. Die Validierung kann Folgendes umfassen:

    • Übereinstimmung der Zeilenzahl für alle an der Migration beteiligten Tabellen.

    • Übereinstimmende Anzahlen für alle Datenbankobjekte (Tabellen, Sequenzen, Erweiterungen, Prozeduren und Indizes).

    • Vergleichen von maximalen oder minimalen IDs von schlüsselanwendungsbezogenen Spalten

      Hinweis

      Die verglichene Größe der Datenbanken muss die richtige Metrik für die Überprüfung sein. Die Quellinstanz kann Überfrachtungen oder inaktive Tupel aufweisen, wodurch die Quellinstanz größer sein kann. Es ist völlig normal, dass Größenunterschiede zwischen Quellinstanzen und Zielservern bestehen. Wenn in den obigen drei Validierungsschritten ein Problem auftritt, deutet dies auf ein Problem mit der Migration hin.

  • Migration von Servereinstellungen: Alle benutzerdefinierten Serverparameter, Firewallregeln (falls zutreffend), Tags und Warnungen müssen manuell von der Quellinstanz zum Ziel kopiert werden.

  • Ändern von Verbindungszeichenfolgen: Die Anwendung sollte ihre Verbindungszeichenfolgen nach erfolgreicher Überprüfung so ändern, dass sie auf einen flexiblen Server verweisen. Diese Aktivität wird mit dem Anwendungsteam koordiniert, um Änderungen an allen Verweisen von Verbindungszeichenfolgen vorzunehmen, die auf die Quellinstanz verweisen. Auf dem flexiblen Server kann der Benutzerparameter im Format Benutzer=Benutzername in der Verbindungszeichenfolge verwendet werden.

Beispiel: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

Obwohl eine Migration oft problemlos verläuft, empfiehlt es sich, für den Fall, dass mehr Zeit für das Debuggen benötigt wird oder die Migration neu gestartet werden muss, entsprechende Vorkehrungen zu treffen.

Benchmarking der Migrationsgeschwindigkeit

Die folgende Tabelle zeigt die erforderliche Zeit für die Durchführung von Migrationen für Datenbanken unterschiedlicher Größe mithilfe des Migrationsdiensts. Die Migration wurde mithilfe eines flexiblen Servers mit folgender SKU durchgeführt: Standard_D4ds_v4 (4 Kerne, 16 GB Arbeitsspeicher).

Datenbankgröße Ungefähre Dauer (HH:MM)
1 GB 00:01
5 GB 00:03
10 GB 00:08
50 GB 00:35
100 GB 01:00
500 GB 04:00
1.000GB 07:00

Die oben genannten Werte geben Ihnen einen ungefähren Anhaltspunkt für die Dauer der Migration. Es wird dringend empfohlen, eine Testmigration mit Ihrer Workload auszuführen, um einen genauen Wert für die Migration Ihres Servers zu erhalten.

Wichtig

Die burstfähige SKU ist zwar keine Einschränkung, es empfiehlt sich jedoch, eine höhere SKU für Ihren flexiblen Server zu wählen, um schnellere Migrationen zu ermöglichen. Azure Database for PostgreSQL – Flexibler Server unterstützt Compute- und IOPS-Skalierung mit nahezu keiner Downtime, sodass die SKU mit minimaler Downtime aktualisiert werden kann. Sie können die SKU immer so ändern, dass sie den Anwendungsanforderungen nach der Migration entspricht.

Verbessern der Migrationsgeschwindigkeit: Parallelmigration von Tabellen

Für das Ziel wird eine leistungsstarke SKU empfohlen, da der PostgreSQL-Migrationsdienst aus einem Container auf dem flexiblen Server ausgeführt wird. Eine leistungsstarke SKU ermöglicht die parallele Migration einer größeren Anzahl von Tabellen. Sie können die SKU nach der Migration wieder auf Ihre bevorzugte Konfiguration skalieren. Dieser Abschnitt enthält Schritte zum Verbessern der Migrationsgeschwindigkeit für den Fall, dass die Datenverteilung zwischen den Tabellen ausgewogener sein muss oder eine leistungsfähigere SKU keine wesentlichen Auswirkungen auf die Migrationsgeschwindigkeit hat.

Wenn die Datenverteilung in der Quelle stark verzerrt ist und die meisten Daten in einer einzigen Tabelle enthalten sind, muss die zugeordnete Computekapazität für die Migration vollständig genutzt werden, wodurch ein Engpass entsteht. Daher werden große Tabellen in kleinere Blöcke aufgeteilt, die dann parallel migriert werden. Diese Funktion gilt für Tabellen mit mehr als 1.000.000 (1 Mio.) Tupeln. Das Aufteilen der Tabelle in kleinere Blöcke ist möglich, wenn eine der folgenden Bedingungen erfüllt ist:

  • Die Tabelle muss über eine Spalte mit einem einfachen (nicht zusammengesetzten) Primärschlüssel oder einem eindeutigen Index vom Typ int oder significant int verfügen.

    Hinweis

    Bei den Ansätzen 1 und 2 müssen Sie die Auswirkungen des Hinzufügens einer eindeutigen Indexspalte zum Quellschema sorgfältig prüfen. Erst nach der Bestätigung, dass das Hinzufügen einer eindeutigen Indexspalte keine Auswirkungen auf die Anwendung hat, sollten Sie mit den Änderungen fortfahren.

  • Wenn die Tabelle keinen einfachen Primärschlüssel oder eindeutigen Index vom Typ int oder significant int aufweist, sondern über eine Spalte verfügt, die die Datentypkriterien erfüllt, kann die Spalte mithilfe des folgenden Befehls in einen eindeutigen Index konvertiert werden. Für diesen Befehl muss die Tabelle nicht gesperrt werden.

        create unique index concurrently partkey_idx on <table name> (column name);

  • Wenn die Tabelle weder über einen einfachen Primärschlüssel vom Typ simple int/big int noch über einen eindeutigen Index oder eine Spalte verfügt, die die Datentypkriterien erfüllt, können Sie eine solche Spalte mit ALTER hinzufügen und nach der Migration löschen. Für die Ausführung des Befehls ALTER muss die Tabelle gesperrt werden.

        alter table <table name> add column <column name> big serial unique;

Wenn eine der oben genannten Bedingungen erfüllt ist, wird die Tabelle in mehreren Partitionen parallel migriert, wodurch die Migrationsgeschwindigkeit deutlich erhöht werden sollte.

Funktionsweise

  • Der Migrationsdienst ermittelt den maximalen und minimalen ganzzahligen Wert des Primärschlüssels/eindeutigen Index der Tabelle, die aufgeteilt und parallel migriert werden soll.
  • Wenn die Differenz zwischen dem Minimal- und Maximalwert größer als 1.000.000 (1 Mio.) ist, wird die Tabelle in mehrere Teile aufgeteilt, und die einzelnen Teile werden getrennt und parallel migriert.

Zusammenfassend lässt sich sagen, dass der PostgreSQL-Migrationsdienst eine Tabelle in parallelen Threads migriert und die Migrationszeit reduziert, wenn eine der folgenden Bedingungen erfüllt ist:

  • Die Tabelle verfügt über eine Spalte mit einem einfachen Primärschlüssel oder einem eindeutigen Index vom Typ „int“ oder „significant int“.
  • Die Tabelle enthält mindestens 1.000.000 (1 Mio.) Zeilen, sodass die Differenz zwischen dem Minimal- und Maximalwert des Primärschlüssels mehr als 1.000.000 (1 Mio.) beträgt.
  • Die verwendete SKU verfügt über Kerne im Leerlauf, die für die parallele Migration der Tabelle genutzt werden können.

Bereinigung einer Aufblähung der PostgreSQL-Datenbank

Wenn Daten im Laufe der Zeit hinzugefügt, aktualisiert und gelöscht werden, können in PostgreSQL tote Zeilen angesammelt und Speicherplatz verschwendet werden. Diese Aufblähung kann zu erhöhten Speicheranforderungen und zu einer verringerten Abfrageleistung führen. Die Bereinigung ist eine wichtige Wartungsaufgabe, die dazu beiträgt, diesen verschwendeten Platz frei zu geben, und sicherstellt, dass die Datenbank effizient funktioniert. Die Bereinigung löst Probleme wie tote Zeilen und die Aufblähung von Tabellen und sorgt für eine effiziente Speichernutzung. Sie trägt auch zur Beschleunigung der Migration bei, da die Migrationszeit von der Größe der Datenbank abhängt.

PostgreSQL stellt den Befehl VACUUM bereit, um den von toten Zeilen belegten Speicher zurückzufordern. Die ANALYZE-Option sammelt ebenfalls Statistiken und optimiert die Abfrageplanung weiter. Bei Tabellen mit starker Schreibaktivität kann der VACUUM-Prozess aggressiver sein, wenn VACUUM FULL verwendet wird. Jedoch erfordert seine Ausführung dann auch mehr Zeit.

  • Standardbereinigung

    VACUUM your_table;

  • Bereinigung mit Analyse

    VACUUM ANALYZE your_table;

  • Aggressive Bereinigung für Tabellen mit starker Schreibaktivität

    VACUUM FULL your_table;

Ersetzen Sie in diesem Beispiel „your_table“ durch den tatsächlichen Tabellennamen. Der Befehl VACUUM ohne FULL fordert Speicherplatz effizient zurück, während VACUUM ANALYZE die Abfrageplanung optimiert. Die VACUUM FULL-Option sollte mit Bedacht eingesetzt werden, da sie die Leistung stärker beeinträchtigt.

Einige Datenbanken speichern große Objekte, z. B. Bilder oder Dokumente, die im Lauf der Zeit zu einer Aufblähung der Datenbank beitragen können. Der VACUUMLO-Befehl wurde für große Objekte in PostgreSQL entwickelt.

  • Bereinigen großer Objekte

    VACUUMLO;

Durch die regelmäßige Anwendung dieser Bereinigungsstrategien wird eine gut gewartete PostgreSQL-Datenbank gewährleistet.

Besondere Überlegungen

Es gibt spezielle Bedingungen, die in der Regel auf eindeutige Umstände, Konfigurationen oder Voraussetzungen verweisen, die Sie kennen müssen, bevor Sie mit einem Tutorial oder Modul fortfahren. Zu diesen Bedingungen können bestimmte Softwareversionen, Hardwareanforderungen oder andere Tools gehören, die zum erfolgreichen Abschluss des Lerninhalts erforderlich sind.

Onlinemigration

Die Onlinemigration verwendet pgcopydb follow, und einige der logischen Dekodierungseinschränkungen gelten. Außerdem empfiehlt es sich, in allen Tabellen einer Datenbank, die einer Onlinemigration unterzogen wird, einen Primärschlüssel anzulegen. Wenn kein Primärschlüssel vorhanden ist, kann dies dazu führen, dass während der Migration nur insert-Vorgänge widergespiegelt und Aktualisierungen oder Löschvorgänge ausgeschlossen werden. Fügen Sie den relevanten Tabellen einen temporären Primärschlüssel hinzu, bevor Sie mit der Onlinemigration fortfahren.

Hinweis

Bei der Onlinemigration von Tabellen ohne Primärschlüssel werden nur insert-Vorgänge für das Ziel wiedergegeben. Dies kann möglicherweise zu Inkonsistenzen in der Datenbank führen, wenn Datensätze, die an der Quelle aktualisiert oder gelöscht werden, nicht am Ziel widergespiegelt werden.

Alternativ können Sie den Befehl ALTER TABLE verwenden, bei dem die Aktion REPLICA IDENTIY mit der Option FULL lautet. Die FULL-Option zeichnet die alten Werte aller Spalten in der Zeile auf, sodass auch bei Abwesenheit eines Primärschlüssels alle CRUD-Vorgänge während der Onlinemigration auf das Ziel angewandt werden. Wenn keine dieser Optionen funktioniert, führen Sie stattdessen eine Offlinemigration aus.

Datenbank mit postgres_fdw-Erweiterung

Das postgres_fdw-Modul stellt den Fremddatenwrapper „postgres_fdw“ bereit, der zum Zugriff auf Daten verwendet werden kann, die auf externen PostgreSQL-Servern gespeichert sind. Falls Ihre Datenbank diese Erweiterung verwendet, müssen Sie die folgenden Schritte ausführen, um eine erfolgreiche Migration sicherzustellen.

  1. Entfernen (Aufheben der Verknüpfung) Sie vorübergehend den Fremddatenwrapper auf der Quellinstanz.
  2. Führen Sie die Migration der ruhenden Daten mithilfe des Migrationsdiensts durch.
  3. Stellen Sie die Rollen „Fremddatenwrapper“, Benutzer und Links zum Ziel nach der Migration wieder her.

Datenbank mit postGIS-Erweiterung

Die postGIS-Erweiterung weist Breaking Changes/Compat-Probleme zwischen verschiedenen Versionen auf. Wenn Sie zu einem flexiblen Server migrieren, muss die Anwendung auf die neuere postGIS-Version überprüft werden, um sicherzustellen, dass die Anwendung nicht beeinträchtigt wird oder dass die erforderlichen Änderungen vorgenommen werden müssen. Die postGIS News und Versionshinweise sind ein guter Ausgangspunkt, um die Breaking Changes zwischen Versionen zu verstehen.

Bereinigung der Datenbankverbindung

Manchmal tritt beim Starten einer Migration dieser Fehler auf:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

In diesem Fall können Sie migration user die Berechtigung erteilen, alle aktiven Verbindungen mit der Datenbank zu schließen, oder schließen Sie die Verbindungen manuell, bevor Sie die Migration wiederholen.

Zugehöriger Inhalt