Bewährte Methoden für eine nahtlose Migration zu Azure Database for PostgreSQL
GILT FÜR:
Azure Database for PostgreSQL – Flexible 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. Dazu können Sie die Optionen Überprüfen und Überprüfen und Migrieren auf der Seite „Migrationseinrichtung“ 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. Wählen Sie Überprüfungen vor der Migration aus, um weitere Informationen zu erhalten.
Konfiguration des flexiblen Zielservers
Während der anfänglichen Basiskopie von Daten werden mehrere Einfügeanweisungen für das 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 ist ratsam, ausreichend Speicherplatz auf der Flexible Server-Instanz zuzuweisen, und zwar etwa 1,25 Mal oder 25 % mehr Speicher als das, was pro Ausgabe des obigen Befehls verwendet wird. Automatische Speichervergrößerung kann auch verwendet werden.
Wichtig
Die Speichergröße kann bei der manuellen Konfiguration oder der automatischen Speichervergrößerung nicht reduziert werden. Jeder Schritt im Speicherkonfigurationsspektrum verdoppelt seine 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. Compute- und Speicheroptionen in Azure Database for PostgreSQL – Flexible Server bietet auch detaillierte Informationen zu jeder Serverkonfiguration.
Migrationszeitachse
Jede Migration hat eine maximale Lebensdauer von sieben Tagen (168 Stunden), nachdem sie gestartet wurde, und läuft nach dem Timeout von sieben Tagen ab. Sie können die Migration und den Anwendungscutover abschließen, sobald 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 ursprü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 kein Datenverlust auftritt. Ebenso sollten Sie bei einer Onlinemigration den Datenverkehr während der gesamten Migration gering halten.
Meistens werden die Nicht-Produktionsserver (Dev, UAT, Test, Staging) mithilfe von Offlinemigrationen migriert. Da diese Server über weniger Daten als die 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 Ihres Produktionsservers durchzuführen und die Offlinemigration auf diesem neu wiederhergestellten Server auszuführen.
Migration des Puffers: Nach Abschluss des oben genannten 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 PITR-Server 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. Kunden können Open-Source-/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, Indizes).
Vergleichen von maximalen oder minimalen IDs von schlüsselanwendungsbezogenen Spalten
Hinweis
Die Größe der Datenbanken muss die richtige Metrik für die Überprüfung sein. Die Quellinstanz kann Überfrachtungen/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 ersten 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 aus der Quellinstanz in das 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 Migrationsdiensts. Die Migration wurde mithilfe eines flexiblen Servers mit folgender SKU durchgeführt: Standard_D4ds_v4 (4 Kerne, 16 GB Arbeitsspeicher, 128 GB Datenträger und 500 IOPS)
| 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 |
Hinweis
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
Wählen Sie eine höhere SKU für Ihren flexiblen Server aus, um schnellere Migrationen durchzuführen. Azure Database for PostgreSQL Flexible Server unterstützt Compute- und IOPS-Skalierung mit nahezu null 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
Im Allgemeinen wird eine leistungsstarke SKU für das Ziel empfohlen, da der PostgreSQL-Migrationsdienst von einem Container auf der Flexible Server-Instanz 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 und/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, ansonsten entsteht ein Engpass. Daher werden große Tabellen in kleinere Blöcke aufgeteilt, die dann parallel migriert werden. Diese Funktion gilt für Tabellen mit mehr als 10.000.000 (10 m) 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 2 und 3 müssen die Benutzer*innen 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, sollte der Benutzer 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 „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 ALTER-Befehls ist eine Sperre für die Tabelle erforderlich.
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 Indexes der Tabelle, die aufgeteilt und parallel migriert werden muss.
- Wenn die Differenz zwischen dem Minimal- und Maximalwert mehr als 10000000 (10 m) beträgt, 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 10.000.000 (10 m) Zeilen, sodass die Differenz zwischen dem Minimal- und Maximalwert des Primärschlüssels mehr als 10.000.000 (10 m) 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. Noch wichtiger ist, dass sie zur Beschleunigung der Migration beiträgt, da die Migrationszeit von der Größe der Datenbank abhängt.
PostgreSQL stellt den VACUUM-Befehl bereit, um den von toten Zeilen belegten Speicher zurückzufordern. Die Option ANALYZE sammelt auch Statistiken und optimiert die Abfrageplanung weiter. Bei Tabellen mit starker Schreibaktivität kann der VACUUM-Prozess aggressiver sein, wenn VACUUM FULLverwendet wird. Jedoch erfordert er mehr Zeit für die Ausführung.
- 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 Option VACUUM FULL 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 Laufe 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 Lernende kennen müssen, bevor Sie mit einem Lernprogramm oder Modul fortfahren. Zu diesen Bedingungen können bestimmte Softwareversionen, Hardwareanforderungen oder zusätzliche Tools gehören, die zum erfolgreichen Abschluss des Lerninhalts erforderlich sind.
Onlinemigration
Die Onlinemigration verwendet pgcopydb follow, und einige der logischen Decodierungseinschränkungen gelten. Zudem 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 Einfügevorgä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.
Alternativ können Sie den Befehl ALTER TABLE verwenden, bei dem die Aktion REPLICA IDENTIY mit der Option FULL lautet. Die Option FULL zeichnet die alten Werte aller Spalten in der Zeile auf, sodass auch bei Abwesenheit eines primären Schlü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 in externen PostgreSQL-Servern gespeicherte Daten verwendet werden kann. Falls Ihre Datenbank diese Erweiterung verwendet, müssen Sie die folgenden Schritte ausführen, um eine erfolgreiche Migration sicherzustellen.
- Entfernen (Aufheben der Verknüpfung) Sie vorübergehend den Fremddatenwrapper für die Quellinstanz.
- Führen Sie die Migration der ruhenden Daten mithilfe des Migrationsdiensts durch.
- 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.