Übertragen von PostgreSQL-Datenbanken zwischen DB-Instances

Mit der Verwendung von PostgreSQL-Transportdatenbanken für Amazon RDS können Sie eine PostgreSQL-Datenbank zwischen zwei DB-Instances bewegen. Dies ist eine sehr schnelle Möglichkeit, große Datenbanken zwischen verschiedenen DB-Instances zu migrieren. Um diesen Ansatz zu verwenden, müssen Ihre DB-Instances beide die gleiche Hauptversion von PostgreSQL ausführen.

Diese Funktion erfordert, dass Sie die pg_transport-Erweiterung sowohl für die Quell- als auch die Ziel-DB-Instance installieren. Die pg_transport-Erweiterung bietet einen physischen Transportmechanismus, der die Datenbankdateien mit minimaler Verarbeitung verschiebt. Dieser Mechanismus bewegt Daten viel schneller als herkömmliche Abfragen- und Ladeprozesse mit weniger Ausfallzeiten.

Anmerkung

PostgreSQL-Transportdatenbanken sind in RDS for PostgreSQL Version 11.5 und höher und RDS for PostgreSQL Version 10.10 und höher verfügbar.

Um eine PostgreSQL-DB-Instance von einer DB-Instance von RDS for PostgreSQL zu einer anderen zu transportieren, richten Sie zuerst die Quell- und Zielinstances ein, wie in Einrichten einer DB-Instance für den Transport beschrieben. Anschließend können Sie die Datenbank mit der unter Transport einer PostgreSQL-Datenbank beschriebenen Funktion transportieren.

Einschränkungen für die Verwendung von PostgreSQL-Transportdatenbanken

Transportdatenbanken haben folgende Einschränkungen:

• Lesereplikate – Sie können keine Transportdatenbanken für Lesereplikate oder übergeordnete Instances von Lesereplikaten verwenden.

• Nicht unterstützte Spaltentypen – Sie können die reg-Datentypen nicht in Datenbanktabellen verwenden, die Sie mit dieser Methode transportieren möchten. Diese Typen hängen von den Objekt-IDs (OIDs) des Systemkatalogs ab, die sich häufig während des Transports ändern.

• Tablespaces – Alle Quelldatenbankobjekte müssen sich im Standard-Tablespace pg_default befinden.

• Kompatibilität – Sowohl die Quell- als auch die Ziel-DB-Instance müssen die gleiche Hauptversion von PostgreSQL ausführen.

• Erweiterungen – Auf der Quell-DB-Instance kann nur das pg_transport installiert sein.

• Rollen und ACLs – Die Zugriffsrechte und Besitzinformationen der Quelldatenbank werden nicht in die Zieldatenbank übertragen. Alle Datenbankobjekte werden erstellt und gehören dem lokalen Zielbenutzer des Transports.

• Gleichzeitige Transporte – Eine einzelne DB-Instance kann bis zu 32 gleichzeitige Transporte unterstützen, einschließlich Importe und Exporte, wenn Worker-Prozesse ordnungsgemäß konfiguriert wurden.

• Nur DB-Instances von RDS for PostgreSQL – Transportable PostgreSQL-Datenbanken werden nur auf DB-Instances von RDS for PostgreSQL unterstützt. Sie können es nicht mit lokalen Datenbanken oder Datenbanken verwenden, die auf Amazon EC2 ausgeführt werden.

Einrichten des Transports einer PostgreSQL-Datenbank

Stellen Sie vor Beginn sicher, dass Ihre DB-Instances von RDS for PostgreSQL die folgenden Anforderungen erfüllen:

• Die DB-Instances von RDS for PostgreSQL für die Quelle und das Ziel müssen die gleiche Version von PostgreSQL ausführen.

• Die Ziel-DB darf keine Datenbank mit dem gleichen Namen wie die Quell-DB haben, die Sie transportieren möchten.

• Das Konto, das Sie zum Ausführen des Transports verwenden, benötigt rds_superuser-Berechtigungen sowohl für die Quell-DB als auch für die Ziel-DB.

• Die Sicherheitsgruppe für die Quell-DB-Instance muss eingehenden Zugriff von der Ziel-DB-Instance zulassen. Dies ist möglicherweise bereits der Fall, wenn sich Ihre Quell- und Ziel-DB-Instances in der VPC befinden. Weitere Informationen zu Sicherheitsgruppen finden Sie unter Zugriffskontrolle mit Sicherheitsgruppen.

Für den Transport von Datenbanken von einer Quell-DB-Instance zu einer Ziel-DB-Instance sind mehrere Änderungen an der DB-Parametergruppe erforderlich, die mit jeder Instance verknüpft ist. Das bedeutet, dass Sie eine benutzerdefinierte DB-Parametergruppe für die Quell-DB-Instance erstellen und eine benutzerdefinierte DB-Parametergruppe für die Ziel-DB-Instance erstellen müssen.

Anmerkung

Wenn Ihre DB-Instances bereits mit benutzerdefinierten DB-Parametergruppen konfiguriert sind, können Sie mit Schritt 2 im folgenden Verfahren beginnen.

Konfigurieren Sie die benutzerdefinierten DB-Gruppenparameter für den Transport von Datenbanken wie folgt:

Verwenden Sie für die folgenden Schritte ein Konto mit rds_superuser-Berechtigungen.

1. Wenn die Quell- und Ziel-DB-Instances eine Standard-DB-Parametergruppe verwenden, müssen Sie eine benutzerdefinierte DB-Parametergruppe mit der entsprechenden Version für Ihre Instances erstellen. Sie tun dies, damit Sie Werte für mehrere Parameter ändern können. Weitere Informationen finden Sie unter Arbeiten mit Parametergruppen.

2. Ändern Sie in der benutzerdefinierten DB-Parametergruppe die Werte für die folgenden Parameter:

   • shared_preload_libraries – Fügen Sie pg_transport zur Liste der Bibliotheken hinzu.

   • pg_transport.num_workers – Der Standardwert ist 3. Erhöhen oder reduzieren Sie diesen Wert nach Bedarf für Ihre Datenbank. Für eine 200-GB-Datenbank empfehlen wir nicht größer als 8. Beachten Sie, dass Sie, wenn Sie den Standardwert für diesen Parameter erhöhen, auch den Wert von max_worker_processes erhöhen sollten.

   • pg_transport.work_mem – Der Standardwert beträgt je nach PostgreSQL-Version entweder 128 MB oder 256 MB. Die Standardeinstellung kann normalerweise unverändert bleiben.

   • max_worker_processes – Der Wert dieses Parameters muss unter Verwendung der folgenden Berechnung festgelegt werden:

     (3 * pg_transport.num_workers) + 9

     Dieser Wert ist am Ziel erforderlich, um verschiedene Hintergrund-Worker-Prozesse abzuwickeln, die am Transport beteiligt sind. Weitere Informationen über max_worker_processes, finden Sie unter Ressourcennutzung in der PostgreSQL-Dokumentation.

   Weitere Informationen zu pg_transport-Parametern finden Sie unter Parameterreferenz für transportable Datenbanken .

3. Starten Sie die Quell-DB-Instances von RDS for PostgreSQL und die Ziel-Instance neu, damit die Einstellungen für die Parameter wirksam werden.

4. Stellen Sie eine Verbindung zu Ihrer Quell-DB-Instance von RDS for PostgreSQL her.

   psql --host=source-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password

5. Entfernen Sie fremde Erweiterungen aus dem öffentlichen Schema der DB-Instance. Während des eigentlichen Transportvorgangs ist nur die pg_transport-Erweiterung zulässig.

6. Installieren Sie die pg_transport-Erweiterung wie folgt:

   postgres=> CREATE EXTENSION pg_transport;
   CREATE EXTENSION

7. Stellen Sie eine Verbindung zu Ihrer Ziel-DB-Instance von RDS for PostgreSQL her. Entfernen Sie alle fremden Erweiterungen und installieren Sie dann die pg_transport-Erweiterung.

   postgres=> CREATE EXTENSION pg_transport;
   CREATE EXTENSION

Transportieren einer PostgreSQL-Datenbank von der Quelle zum Ziel

Nachdem Sie den in Einrichten des Transports einer PostgreSQL-Datenbank beschriebenen Prozess abgeschlossen haben, können Sie den Transport starten. Führen Sie dazu die Funktion transport.import_from_server auf der Ziel-DB-Instance aus. In der folgenden Syntax finden Sie die Funktionsparameter.

SELECT transport.import_from_server( 
   'source-db-instance-endpoint', 
    source-db-instance-port, 
   'source-db-instance-user', 
   'source-user-password', 
   'source-database-name', 
   'destination-user-password', 
   false);

Der im Beispiel gezeigte false-Wert teilt der Funktion mit, dass es sich nicht um einen Trockenlauf handelt. Um die Transporteinrichtung zu testen, können Sie true für die Option dry_run angeben, wenn Sie die Funktion aufrufen, wie im Folgenden gezeigt:

postgres=> SELECT transport.import_from_server(
    'docs-lab-source-db.666666666666aws-region.rds.amazonaws.com', 5432,
    'postgres', '********', 'labdb', '******', true);
INFO:  Starting dry-run of import of database "labdb".
INFO:  Created connections to remote database        (took 0.03 seconds).
INFO:  Checked remote cluster compatibility          (took 0.05 seconds).
INFO:  Dry-run complete                         (took 0.08 seconds total).
 import_from_server
--------------------

(1 row)

Die INFO-Zeilen werden ausgegeben, da der pg_transport.timing-Parameter auf seinen Standardwert eingestellt ist, true. Legen Sie dry_run auf false fest, wenn Sie den Befehl ausführen und die Quelldatenbank wie folgt in das Ziel importiert wird:

INFO:  Starting import of database "labdb".
INFO:  Created connections to remote database        (took 0.02 seconds).
INFO:  Marked remote database as read only           (took 0.13 seconds).
INFO:  Checked remote cluster compatibility          (took 0.03 seconds).
INFO:  Signaled creation of PITR blackout window     (took 2.01 seconds).
INFO:  Applied remote database schema pre-data       (took 0.50 seconds).
INFO:  Created connections to local cluster          (took 0.01 seconds).
INFO:  Locked down destination database              (took 0.00 seconds).
INFO:  Completed transfer of database files          (took 0.24 seconds).
INFO:  Completed clean up                            (took 1.02 seconds).
INFO:  Physical transport complete              (took 3.97 seconds total).
import_from_server
--------------------
(1 row)

Für diese Funktion müssen Sie Passwörter für Datenbankbenutzer angeben. Daher empfehlen wir Ihnen, die Passwörter der Benutzerrollen, die Sie für den Transportvorgang verwendet haben, nach Abschluss des Transports zu ändern. Oder Sie können SQL-Bind-Variablen verwenden, um temporäre Benutzerrollen zu erstellen. Verwenden Sie diese temporären Rollen für den Transport und entfernen Sie die Rollen anschließend.

Falls Ihr Transport nicht erfolgreich ist, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

pg_transport.num_workers=8 25% of files transported failed to download file data

Die Fehlermeldung „Dateidaten konnte nicht heruntergeladen werden“ zeigt an, dass die Anzahl der Worker-Prozesse für die Größe der Datenbank nicht korrekt festgelegt ist. Möglicherweise müssen Sie den für pg_transport.num_workers festgelegten Wert erhöhen oder verringern. Jeder Fehler meldet den Prozentsatz der Fertigstellung, sodass Sie die Auswirkungen Ihrer Änderungen sehen können. Wenn Sie beispielsweise die Einstellung in einem Fall von 8 auf 4 ändern, führte dies zu Folgendem:

pg_transport.num_workers=4 75% of files transported failed to download file data

Beachten Sie, dass der Parameter max_worker_processes auch während des Transportvorgangs berücksichtigt wird. Mit anderen Worten, Sie müssen möglicherweise sowohl pg_transport.num_workers als auch max_worker_processes ändern, um die Datenbank erfolgreich zu transportieren. Das gezeigte Beispiel hat endlich funktioniert, als die pg_transport.num_workers wurde auf 2 eingestellt wurde:

pg_transport.num_workers=2 100% of files transported

Weitere Hinweise zur transport.import_from_server-Funktion und ihren Parametern finden Sie unter Funktionsreferenz für transportable Datenbanken.

Was passiert beim Datenbanktransport?

Die Funktion PostgreSQL-Transportdatenbanken verwendet ein Pull-Modell, um die Datenbank aus der Quell-DB-Instance in das Ziel zu importieren. Die transport.import_from_server-Funktion erstellt die In-Transit-Datenbank auf der Ziel-DB-Instance. Die In-Transit-Datenbank ist auf der Ziel-DB-Instance für die Dauer des Transports nicht zugänglich.

Wenn der Transport beginnt, werden alle aktuellen Sitzungen auf der Quelldatenbank beendet. Alle anderen Datenbanken als die Quelldatenbank auf der Quell-DB-Instance sind vom Transport nicht betroffen.

Die Quelldatenbank wird in einen speziellen schreibgeschützten Modus versetzt. Während es sich in diesem Modus befindet, können Sie sich mit der Quelldatenbank verbinden und schreibgeschützte Abfragen durchführen. Allerdings sind schreibende Abfragen und einige andere Arten von Befehlen blockiert. Von diesen Einschränkungen ist nur die spezifische Quelldatenbank betroffen, die transportiert wird.

Während des Transports können Sie für die Ziel-DB-Instance keine Point-in-time-Wiederherstellung durchführen. Dies liegt daran, dass der Transport nicht transaktional ist und das PostgreSQL-Write-Ahead-Protokoll nicht verwendet, um Änderungen aufzuzeichnen. Wenn in der Ziel-DB-Instance das automatische Backup aktiviert ist, wird nach Abschluss des Transports automatisch ein Backup durchgeführt. oint-in-time P-Wiederherstellungen sind für bestimmte Zeiten nach Abschluss des Backups verfügbar.

Wenn der Transport fehlschlägt, versucht die pg_transport-Erweiterung, alle Änderungen an den Quell- und Ziel-DB-Instances rückgängig zu machen. Dazu gehört auch das Entfernen der teilweise transportierten Datenbank auf dem Ziel. Abhängig von der Art des Fehlers kann es vorkommen, dass die Quelldatenbank weiterhin schreibende Abfragen ablehnt. Verwenden Sie in diesem Fall den folgenden Befehl, um schreibende Abfragen zu ermöglichen.

ALTER DATABASE db-name SET default_transaction_read_only = false;

Funktionsreferenz für transportable Datenbanken

Die transport.import_from_server-Funktion transportiert eine PostgreSQL-Datenbank, indem sie sie von einer Quell-DB-Instance in eine Ziel-DB-Instance importiert. Dies geschieht durch die Verwendung eines physischen Datenbankverbindungs-Transportmechanismus.

Vor dem Start des Transports überprüft diese Funktion, ob die Quell- und Ziel-DB-Instances dieselbe Version haben und für die Migration kompatibel sind. Es bestätigt auch, dass die Ziel-DB-Instance über genügend Speicherplatz für die Quelle verfügt.

Syntax

transport.import_from_server(
   host text,
   port int,
   username text,
   password text,
   database text,
   local_password text,
   dry_run bool
)

Rückgabewert

Keine.

Parameter

Die Beschreibung der Parameter der transport.import_from_server-Funktion finden Sie in der folgenden Tabelle.

Parameter	Beschreibung
host	Der Endpunkt der Quell-DB-Instance.
port	Eine ganze Zahl, die den Port der Quell-DB-Instance darstellt. PostgreSQL DB-Instances verwenden häufig den Port 5432.
username	Der Benutzer der Quell-DB-Instance. Dieser Benutzer muss Mitglied der Rolle rds_superuser sein.
password	Das Benutzerpasswort der Quell-DB-Instance.
database	Der Name der Datenbank in der zu transportierenden Quell-DB-Instance.
local_password	Das lokale Passwort des aktuellen Benutzers für die Ziel-DB-Instance. Dieser Benutzer muss Mitglied der Rolle rds_superuser sein.
dry_run	Ein optionaler boolescher Wert, der angibt, ob ein Trockenlauf durchgeführt werden soll. Die Voreinstellung ist false, was bedeutet, dass der Transport durchgeführt wird. Um die Kompatibilität zwischen der Quell- und der Ziel-DB-Instance zu bestätigen, ohne den eigentlichen Transport durchzuführen, legen Sie dry_run auf true fest.

Beispiel

Ein Beispiel finden Sie unter Transportieren einer PostgreSQL-Datenbank von der Quelle zum Ziel.

Parameterreferenz für transportable Datenbanken

Mehrere Parameter steuern das Verhalten der pg_transport-Erweiterung. Im Folgenden finden Sie Beschreibungen dieser Parameter.

pg_transport.num_workers

Die Anzahl der für den Transportprozess zu verwendenden Worker. Die Voreinstellung ist 3. Gültige Werte sind 1–32. Selbst die größten Datenbanktransporte erfordern in der Regel weniger als acht Worker. Der Wert dieser Einstellung für die Ziel-DB-Instance wird während des Transports sowohl vom Ziel als auch von der Quelle verwendet.

pg_transport.timing

Gibt an, ob während des Transports Zeitinformationen übermittelt werden sollen. Der Standardwert ist true, was bedeutet, dass Zeitinformationen gemeldet werden. Es wird empfohlen, diesen Parameter auf true festzulegen, damit Sie den Fortschritt überwachen können. Eine Beispielausgabe finden Sie unter Transportieren einer PostgreSQL-Datenbank von der Quelle zum Ziel.

pg_transport.work_mem

Die maximale Menge an Speicher, die für jeden Worker zugewiesen werden kann. Der Standardwert ist 131072 Kilobyte (KB) oder 262144 KB (256 MB), abhängig von der PostgreSQL-Version. Der Mindestwert beträgt 64 Megabyte (65536 KB). Gültige Werte sind Kilobyte-Werte (KBs) als Vielfaches von 2. Dabei gilt: 1 KB = 1024 Bytes.

Der Transport benötigt möglicherweise weniger Speicher als in diesem Parameter angegeben. Selbst große Datenbanktransporte benötigen normalerweise weniger als 256 MB (262144 KB) Speicher pro Worker.