Verwenden der logischen Replikation, um ein Hauptversions-Upgrade für Aurora PostgreSQL durchzuführen

Wenn Sie die logische Replikation und schnelles Aurora-Klonen verwenden, können Sie ein Hauptversions-Upgrade unter Verwendung der aktuellen Version der Aurora-PostgreSQL-Datenbank durchführen, während Sie die sich ändernden Daten schrittweise auf die neue Hauptversionsdatenbank migrieren. Dieser Upgrade-Prozess mit geringen Ausfallzeiten wird als Blau/Grün-Upgrade bezeichnet. Die aktuelle Version der Datenbank wird als „blaue“ Umgebung und die neue Datenbankversion als „grüne“ Umgebung bezeichnet.

Dank des schnellen Klonens von Aurora werden die vorhandenen Daten vollständig geladen, indem ein Snapshot der Quelldatenbank erstellt wird. Das schnelle Klonen verwendet ein copy-on-write Protokoll, das auf der Aurora-Speicherschicht aufbaut, sodass Sie in kurzer Zeit einen Klon der Datenbank erstellen können. Diese Methode ist sehr effektiv beim Upgrade auf eine große Datenbank.

Die logische Replikation in PostgreSQL verfolgt und überträgt Ihre Datenänderungen von der ursprünglichen Instance auf eine neue Instance, die parallel läuft, bis Sie zur neueren Version von PostgreSQL wechseln. Für die logische Replikation wird ein Veröffentlichungs- und Abonnementmodell verwendet. Weitere Informationen über die logische Replikation von Aurora PostgreSQL finden Sie unter Replikation mit Amazon Aurora PostgreSQL.

Tipp

Sie können die für ein Hauptversions-Upgrade erforderlichen Ausfallzeiten minimieren, indem Sie die verwaltete Blau/Grün-Bereitstellungsfunktion von Amazon RDS verwenden. Weitere Informationen finden Sie unter Verwendung von Blau/Grün-Bereitstellungen von Amazon RDS für Datenbankaktualisierungen.

Voraussetzungen

Sie müssen die folgenden Anforderungen erfüllen, um diesen Upgrade-Prozess mit geringen Ausfallzeiten durchzuführen:

• Sie müssen über rds_superuser-Berechtigungen verfügen.

• Auf dem DB-Cluster von Aurora PostgreSQL, den Sie aktualisieren möchten, muss eine unterstützte Version ausgeführt werden, die mithilfe logischer Replikation Hauptversions-Upgrades durchführen kann. Sie müssen alle Nebenversions-Updates und -Patches auf Ihren DB-Cluster anwenden. Die aurora_volume_logical_start_lsn-Funktion, die bei dieser Methode zum Einsatz kommt, wird in den folgenden Versionen von Aurora PostgreSQL unterstützt:

  • 15.2 und höhere 15-Versionen

  • 14.3 und höhere 14-Versionen

  • 13.6 und höhere 13-Versionen

  • 12.10 und höhere 12-Versionen

  • 11.15 und höhere 11-Versionen

  • 10.20 und höhere 10-Versionen

  Weitere Informationen über die aurora_volume_logical_start_lsn-Funktion finden Sie unter aurora_volume_logical_start_lsn.

• Alle Ihre Tabellen müssen einen Primärschlüssel haben oder eine PostgreSQL-Identitätsspalte enthalten.

• Konfigurieren Sie die Sicherheitsgruppe für Ihre VPC, um eingehenden und ausgehenden Zugriff zwischen den beiden DB-Clustern von Aurora PostgreSQL (dem alten und dem neuen) zu ermöglichen. Sie können Zugriff auf einen speziellen Classless Inter-Domain Routing (CIDR)-Bereich oder auf eine andere Sicherheitsgruppe in Ihrer VPC oder einer Peer-VPC gewähren. (Eine Peer-VPC erfordert eine VPC-Peering-Verbindung.)

Anmerkung

Detaillierte Informationen zu den Berechtigungen, die für die Konfiguration und Verwaltung eines laufenden logischen Replikationsszenarios erforderlich sind, finden Sie in der PostgreSQL-Core-Dokumentation.

Einschränkungen

Wenn Sie ein Upgrade mit niedriger Ausfallzeit für Ihren DB-Cluster von Aurora PostgreSQL durchführen, um ihn auf eine neue Hauptversion zu aktualisieren, verwenden Sie die native logische PostgreSQL-Replikationsfunktion. Sie weist die gleichen Fähigkeiten und Einschränkungen wie die logische PostgreSQL-Replikation auf. Weitere Informationen finden Sie unter Die logische Replikation von PostgreSQL.

• Data Definition Language (DDL)-Befehle werden nicht repliziert.

• Die Replikation unterstützt keine Schemaänderungen in einer Live-Datenbank. Das Schema wird während des Klonvorgangs in seiner ursprünglichen Form neu erstellt. Wenn Sie das Schema nach dem Klonen, aber vor Abschluss des Upgrades ändern, werden die Änderungen nicht in der aktualisierten Instance angezeigt.

• Große Objekte werden nicht repliziert, aber Sie können Daten in normalen Tabellen speichern.

• Die Replikation wird nur von Tabellen unterstützt, einschließlich partitionierter Tabellen. Die Replikation auf andere Relationstypen wie Ansichten, materialisierte Ansichten oder fremde Tabellen wird nicht unterstützt.

• Sequenzdaten werden nicht repliziert und müssen nach dem Failover manuell aktualisiert werden.

Anmerkung

Dieses Upgrade unterstützt kein Auto-Scripting. Sie sollten alle Schritte manuell ausführen.

Festlegen und Überprüfen von Parameterwerten

Vor dem Upgrade müssen Sie die Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL so konfigurieren, dass sie als Veröffentlichungsserver fungiert. Die Instance sollte eine benutzerdefinierte DB-Cluster-Parametergruppe mit den folgenden Einstellungen verwenden:

• rds.logical_replication – Stellen Sie diesen Parameter auf 1 ein. Der rds.logical_replication-Parameter dient demselben Zweck wie der Parameter wal_level eines eigenständigen PostgreSQL-Servers und andere Parameter, die die Write-Ahead-Protokolldateiverwaltung steuern.

• max_replication_slots – Legen Sie diesen Parameter auf die Gesamtzahl der Abonnements fest, die Sie erstellen möchten. Wenn Sie verwenden AWS DMS, legen Sie diesen Parameter auf die Anzahl der AWS DMS Aufgaben fest, die Sie für die Erfassung geänderter Daten aus diesem DB-Cluster verwenden möchten.

• max_wal_senders – Legen Sie die Anzahl der gleichzeitigen Verbindungen sowie einige zusätzliche Verbindungen fest, um sie für Verwaltungsaufgaben und neue Sitzungen verfügbar zu machen. Wenn Sie verwenden AWS DMS, sollte die Anzahl der max_wal_senders der Anzahl der gleichzeitigen Sitzungen plus der Anzahl der AWS DMS Aufgaben entsprechen, die zu einem bestimmten Zeitpunkt möglicherweise funktionieren.

• max_logical_replication_workers – Legen Sie diesen Parameter auf die Anzahl der Worker für logische Replikation und Tabellensynchronisierung fest, die Sie erwarten. Im Allgemeinen ist es sicher, die Anzahl der Replikations-Worker auf den gleichen Wert festzulegen, der für max_wal_senders verwendet wird. Die Worker stammen aus dem Pool der Hintergrundprozesse (max_worker_processes), die dem Server zugewiesen sind.

• max_worker_processes – Legen Sie diesen Parameter auf die Anzahl der Hintergrundprozesse für den Server fest. Diese Anzahl sollte groß genug sein, um Worker für Replikation, Selbstbereinigungsprozesse und andere Wartungsprozesse, die möglicherweise gleichzeitig stattfinden, zur Verfügung zu stellen.

Wenn Sie auf eine neuere Version von Aurora PostgreSQL aktualisieren, müssen Sie alle Parameter duplizieren, die Sie in der früheren Version der Parametergruppe geändert haben. Diese Parameter werden auf die aktualisierte Version angewendet. Sie können die pg_settings-Tabelle abfragen, um eine Liste der Parametereinstellungen zu erhalten, sodass Sie sie in Ihrem neuen DB-Cluster von Aurora PostgreSQL neu erstellen können.

Führen Sie beispielsweise die folgende Abfrage aus, um die Einstellungen für Replikationsparameter abzurufen:

SELECT name, setting FROM pg_settings WHERE name in 
('rds.logical_replication', 'max_replication_slots', 
'max_wal_senders', 'max_logical_replication_workers', 
'max_worker_processes');

Durchführen eines Upgrades von Aurora PostgreSQL auf eine neue Hauptversion

So bereiten Sie den Herausgeber vor (blau)

1. Im folgenden Beispiel ist die Writer-Quell-Instance (blau) ein DB-Cluster von Aurora PostgreSQL, auf dem PostgreSQL Version 11.15 ausgeführt wird. Dies ist der Veröffentlichungsknoten in unserem Replikationsszenario. Für diese Demonstration hostet unsere Writer-Quell-Instance eine Beispieltabelle, die eine Reihe von Werten enthält:

   CREATE TABLE my_table (a int PRIMARY KEY);
   INSERT INTO my_table VALUES (generate_series(1,100));

2. Um eine Publikation auf der Quell-Instance zu erstellen, stellen Sie mit psql (die CLI für PostgreSQL) oder mit dem Client Ihrer Wahl eine Verbindung zum Writer-Knoten der Instance her. Geben Sie in jeder Datenbank den folgenden Befehl ein:

   CREATE PUBLICATION publication_name FOR ALL TABLES;

   Der Wert publication_name gibt den Namen der Publikation an.

3. Sie müssen auch einen Replikations-Slot auf der Instance erstellen. Der folgende Befehl erstellt einen Replikations-Slot und lädt das logische Dekodierungs-Plug-in pgoutput. Das Plug-in ändert den von Write-Ahead Logging (WAL) in das logische Replikationsprotokoll gelesenen Inhalt und filtert die Daten gemäß der Veröffentlichungsspezifikation.

   SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');

So klonen Sie den Herausgeber

1. Verwenden Sie die Amazon-RDS-Konsole, um einen Klon der Quell-Instance zu erstellen. Markieren Sie den Instance-Namen in der Amazon-RDS-Konsole und wählen Sie dann im Menü Actions (Aktionen) die Option Create Clone (Klon erstellen) aus.

   

2. Geben Sie einen eindeutigen Namen für die Instance ein. Die meisten Einstellungen sind Standardeinstellungen aus der Quell-Instance. Wenn Sie die für die neue Instance erforderlichen Änderungen vorgenommen haben, wählen Sie Create clone (Klon erstellen) aus.

   

3. Während die Ziel-Instance initiiert wird, wird in der Spalte Status des Writer-Knotens Creating angezeigt. Sobald die Instance bereit ist, ändert sich ihr Status in „Available“.

So bereiten Sie den Klon für ein Upgrade vor

1. Der Klon ist die „grüne“ Instance im Bereitstellungsmodell. Er ist der Host des Replikationsabonnementknotens. Wenn der Knoten verfügbar ist, stellen Sie eine Verbindung mit psql her und fragen Sie den neuen Writer-Knoten ab, um die Log-Sequenznummer (LSN) zu erhalten. Die LSN identifiziert den Anfang eines Datensatzes im WAL-Stream.

   SELECT aurora_volume_logical_start_lsn();

2. Die LSN-Nummer finden Sie in der Antwort auf die Abfrage. Da Sie diese Nummer zu einem späteren Zeitpunkt des Vorgangs benötigen, sollten Sie sich diese notieren.

   postgres=> SELECT aurora_volume_logical_start_lsn();
   aurora_volume_logical_start_lsn 
   ---------------
   0/402E2F0
   (1 row)
   

3. Bevor Sie den Klon aktualisieren, löschen Sie den Replikationsslot des Klons.

   SELECT pg_drop_replication_slot('replication_slot_name');

So aktualisieren Sie einen Cluster auf eine neue Hauptversion

• Verwenden Sie nach dem Klonen des Provider-Knotens die Amazon-RDS-Konsole, um ein Hauptversions-Upgrade auf dem Abonnementknoten zu initiieren. Markieren Sie den Instance-Namen in der RDS-Konsole und klicken Sie auf die Schaltfläche Modify (Ändern). Wählen Sie die aktualisierte Version und Ihre aktualisierten Parametergruppen aus und wenden Sie die Einstellungen sofort an, um die Ziel-Instance zu aktualisieren.

  

• Sie können auch die CLI verwenden, um ein Upgrade durchzuführen:

  aws rds modify-db-cluster —db-cluster-identifier $TARGET_Aurora_ID —engine-version 13.6 —allow-major-version-upgrade —apply-immediately

So bereiten Sie den Abonnenten (grün) vor

1. Sobald der Klon nach dem Upgrade verfügbar ist, stellen Sie eine Verbindung mit psql her und definieren Sie das Abonnement. Dazu müssen Sie die folgenden Optionen im CREATE SUBSCRIPTION-Befehl angeben:

   • subscription_name – Der Name des Abonnements.

   • admin_user_name – Der Name eines Administratorbenutzers mit rds_superuser-Berechtigungen.

   • admin_user_password – Das Passwort, das dem Administrator zugeordnet ist.

   • source_instance_URL – Die URL der Veröffentlichungsserver-Instance.

   • database – Die Datenbank, mit der der Abonnementserver eine Verbindung herstellen wird.

   • publication_name – Der Name des Veröffentlichungsservers.

   • replication_slot_name – Der Name der Replikationsgruppe.

   CREATE SUBSCRIPTION subscription_name 
   CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name 
   WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');

2. Nachdem Sie das Abonnement erstellt haben, fragen Sie die Ansicht pg_replication_origin ab, um den Roname-Wert abzurufen. Dieser Wert ist die ID des Replikationsursprungs. Jede Instance hat einen roname-Wert:

   SELECT * FROM pg_replication_origin;

   Beispielsweise:

   postgres=> 
   SELECT * FROM pg_replication_origin;
    
   roident | roname 
   ---------+----------
   1 | pg_24586
   

3. Geben Sie im Befehl die LSN an, die Sie aus der vorherigen Abfrage des Veröffentlichungsknotens gespeichert haben, und den roname-Wert, der vom Abonnementknoten [INSTANCE] zurückgegeben wurde. Dieser Befehl verwendet die pg_replication_origin_advance-Funktion, um den Ausgangspunkt in der Protokollsequenz für die Replikation anzugeben.

   SELECT pg_replication_origin_advance('roname', 'log_sequence_number');

   roname ist die ID, die von der Ansicht pg_replication_origin zurückgegeben wird.

   log_sequence_number ist der Wert, der von der vorherigen Abfrage der aurora_volume_logical_start_lsn-Funktion zurückgegeben wurde.

4. Verwenden Sie dann die ALTER SUBSCRIPTION... ENABLE-Klausel, um die logische Replikation zu aktivieren.

   ALTER SUBSCRIPTION subscription_name ENABLE;

5. An dieser Stelle können Sie bestätigen, dass die Replikation funktioniert. Fügen Sie der Veröffentlichungs-Instance einen Wert hinzu und bestätigen Sie dann, dass der Wert auf den Abonnementknoten repliziert wird.

   Verwenden Sie dann den folgenden Befehl, um die Replikationsverzögerung auf dem Veröffentlichungsknoten zu überwachen:

   SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),
   confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(),
   confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';

   Beispielsweise:

   postgres=> SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 
   confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';
    
   current_time                   | slot_name             | active | active_pid | diff_size | diff_bytes 
   -------------------------------+-----------------------+--------+------------+-----------+------------
   2022-04-13 15:11:00.243401+00  | replication_slot_name | t      | 21854      | 136 bytes | 136
   (1 row)
   

   Sie können die Replikationsverzögerung mit den Werten diff_size unddiff_bytes überwachen. Wenn diese Werte 0 erreichen, hat das Replikat den Stand der Quell-DB-Instance erreicht.

Durchführen von Aufgaben nach dem Upgrade

Wenn das Upgrade abgeschlossen ist, wird der Instance-Status in der Spalte Status des Konsolen-Dashboards als Available angezeigt. Für die neue Instance empfehlen wir Ihnen Folgendes:

• Leiten Sie Ihre Anwendungen so um, dass sie auf den Writer-Knoten verweisen.

• Fügen Sie Reader-Knoten hinzu, um die Fallzahl zu verwalten und eine hohe Verfügbarkeit zu gewährleisten, falls ein Problem mit dem Writer-Knoten auftritt.

• DB-Cluster von Aurora PostgreSQL erfordern gelegentlich Betriebssystem-Updates. Diese Updates können eine neuere Version der Glibc-Bibliothek umfassen. Bei solchen Updates empfehlen wir Ihnen, die unter In Aurora PostgreSQL unterstützte Sortierungen beschriebenen Richtlinien zu befolgen.

• Aktualisieren Sie die Benutzerberechtigungen für die neue Instance, um den Zugriff sicherzustellen.

Nachdem Sie Ihre Anwendung und Daten auf der neuen Instance getestet haben, empfehlen wir Ihnen, ein letztes Backup Ihrer ersten Instance zu erstellen, bevor Sie sie entfernen. Weitere Informationen zur Verwendung der logischen Replikation auf einem Aurora-Host finden Sie unter Einrichten der logischen Replikation für Ihren DB-Cluster von Aurora PostgreSQL.