So führen Sie ein Hauptversions-Upgrade RDS für Postgre durch SQL - Amazon Relational Database Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

So führen Sie ein Hauptversions-Upgrade RDS für Postgre durch SQL

Wir empfehlen den folgenden Vorgang, wenn Sie ein Hauptversions-Upgrade für eine Amazon RDS for SQL Postgre-Datenbank durchführen:

  1. Bereithalten einer versionskompatiblen Parametergruppe – Wenn Sie eine benutzerdefinierte Parametergruppe verwenden, haben Sie zwei Optionen. Sie können eine Standardparametergruppe für die neue DB-Engine-Version angeben. Oder Sie können eine eigene benutzerdefinierte Parametergruppe für die neue DB-Engine-Version erstellen. Weitere Informationen erhalten Sie unter Parametergruppen für Amazon RDS und Arbeiten mit DB-Cluster-Parametergruppen für Multi-AZ-DB-Cluster.

  2. Suchen Sie nach nicht unterstützten Datenbankklassen — Vergewissern Sie sich, dass die Instance-Klasse Ihrer Datenbank mit der SQL Postgre-Version kompatibel ist, auf die Sie ein Upgrade durchführen. Weitere Informationen finden Sie unter Unterstützte DB-Engines für DB-Instance-Klassen.

  3. Auf nicht unterstützte Verwendung prüfen:

    • Vorbereitete Transaktionen: Übernehmen Sie oder machen Sie alle offenen vorbereiteten Transaktionen rückgängig, bevor Sie ein Upgrade durchführen.

      Mit der folgenden Abfrage können Sie sicherstellen, dass für Ihre Datenbank keine geöffneten vorbereiteten Transaktionen vorhanden sind. 

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

    • Reg*-Datentypen – Entfernen Sie alle Anwendungen der reg*-Datentypen, bevor Sie versuchen, einen Upgrade durchzuführen. Bis auf regtype und regclass ist kein Upgrade der reg*-Datentypen möglich. Das pg_upgrade Hilfsprogramm kann diesen Datentyp, der von Amazon für das Upgrade verwendet wirdRDS, nicht beibehalten.

      Um zu überprüfen, dass keine Anwendungen der nicht unterstützten reg*-Datentypen vorhanden sind, geben Sie für jede Datenbank die folgende Abfrage aus. 

      
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
  WHERE c.oid = a.attrelid
      AND NOT a.attisdropped
      AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
                         'pg_catalog.regprocedure'::pg_catalog.regtype,
                         'pg_catalog.regoper'::pg_catalog.regtype,
                         'pg_catalog.regoperator'::pg_catalog.regtype,
                         'pg_catalog.regconfig'::pg_catalog.regtype,
                         'pg_catalog.regdictionary'::pg_catalog.regtype)
      AND c.relnamespace = n.oid
      AND n.nspname NOT IN ('pg_catalog', 'information_schema');

  4. Suchen Sie nach ungültigen Datenbanken:

    • Stellen Sie sicher, dass keine ungültigen Datenbanken vorhanden sind. Die datconnlimit Spalte im pg_database Katalog enthält den Wert, -2 um Datenbanken, die während eines DROP DATABASE Vorgangs unterbrochen wurden, als ungültig zu kennzeichnen.

      Verwenden Sie die folgende Abfrage, um nach ungültigen Datenbanken zu suchen:

      SELECT datname FROM pg_database WHERE datconnlimit = - 2;

    • Die vorherige Abfrage gibt ungültige Datenbanknamen zurück. Sie können sie verwendenDROP DATABASE invalid_db_name;, um ungültige Datenbanken zu löschen. Sie können auch den folgenden Befehl verwenden, um ungültige Datenbanken zu löschen:

      SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec

    Weitere Informationen zu ungültigen Datenbanken finden Sie unter Grundlegendes zum Verhalten von Autovacuum bei ungültigen Datenbanken.

  5. Umgang mit logischen Replikations-Slots – Ein Upgrade ist nicht möglich, wenn die Datenbank über logische Replikations-Slots verfügt. Logische Replikations-Slots werden normalerweise für die AWS DMS -Migration verwendet und zum Replizieren Datenbanktabellen in Data Lakes, BI-Tools und anderen Zielen. Stellen Sie vor dem Upgrade sicher, dass Sie den Zweck aller verwendeten logischen Replikations-Slots kennen, und bestätigen Sie, dass sie gelöscht werden können. Wenn die logischen Replikations-Slots noch verwendet werden, sollten Sie sie nicht löschen, und Sie können mit dem Upgrade nicht fortfahren.

    Wenn die Steckplätze für die logische Replikation nicht benötigt werden, können Sie sie wie folgt SQL löschen:

    SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

    Für die Einrichtung von logische Replikationsszenarien, die die pglogical-Erweiterung verwenden, müssen außerdem Slots gelöscht werden, damit ein Hauptversions-Upgrade erfolgreich durchgeführt werden kann. Informationen zum Identifizieren und Löschen von Slots, die mit der pglogical-Erweiterung erstellt wurden, finden Sie unter Verwaltung logischer Replikationssteckplätze für for Postgre SQL.

  6. Behandlung von Lesereplikaten – Bei einem Upgrade Single-AZ-DB-Instance- oder Multi-AZ-DB-Instance-Bereitstellung werden neben der primären DB-Instance auch die Lesereplikate in der Region aktualisiert. Amazon führt RDS kein Upgrade von Multi-AZ-DB-Cluster-Read Replicas durch.

    Lesereplikate können nicht separat aktualisiert werden. Wenn Sie könnten, könnte dies zu Situationen führen, in denen die Primär- und Replikatdatenbanken unterschiedliche SQL Postgre-Hauptversionen haben. Lesereplika-Upgrades können jedoch die Ausfallzeit der primären DB-Instance erhöhen. Um ein Lesereplikat-Upgrade zu verhindern, befördern Sie das Replikat zu einer eigenständigen Instance oder löschen Sie es, bevor Sie den Upgrade-Prozess starten.

    Der Upgrade-Prozess erstellt die Parametergruppe des Lesereplikats auf der Grundlage der aktuellen Parametergruppe des Lesereplikats neu. Sie können eine benutzerdefinierte Parametergruppe erst dann auf ein Lesereplikat anwenden, wenn die Aktualisierung abgeschlossen ist, indem Sie das Lesereplikat modifizieren. Weitere Informationen über Lesereplikate finden Sie unter Arbeiten mit Read Replicas für Amazon RDS for Postgre SQL.

  7. Durchführen einer Sicherung – Wir empfehlen, vor dem Upgrade der Hauptversion eine Sicherung durchzuführen, damit Sie über einen bekannten Wiederherstellungspunkt für Ihre Datenbank verfügen. Wenn der Wert des Aufbewahrungszeitraums für Ihre Sicherung größer als 0 ist, erstellt der Upgrade-Vorgang vor und nach der Aktualisierung DB-Snapshots Ihrer Datenbank. Informationen über das Ändern Ihres Aufbewahrungszeitraums für Backups finden Sie unter Ändern einer Amazon RDS DB-Instance und Ändern eines Multi-AZ-DB-Clusters für Amazon RDS.

    Informationen zum manuellen Durchführen der Sicherung finden Sie unter Erstellen eines DB-Snapshots für eine Single-AZ-DB-Instance für Amazon RDS und Erstellen eines Multi-AZ-DB-Cluster-Snapshots für Amazon RDS.

  8. Aktualisieren bestimmter Erweiterungen vor dem Upgrade der Hauptversion – Wenn Sie planen, eine Hauptversion mit dem Upgrade zu überspringen, müssen Sie bestimmte Erweiterungen aktualisieren bevor Sie das Upgrade der Hauptversion durchführen. Zum Beispiel überspringt ein Upgrade von den Versionen 9.5.x oder 9.6.x auf die Versionen 11.x eine Hauptversion. Zu den zu aktualisierenden Erweiterungen gehören Post GIS und verwandte Erweiterungen für die Verarbeitung von Geodaten.

    • address_standardizer

    • address_standardizer_data_us

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    Führen Sie den folgenden Befehl für jede von Ihnen verwendete Erweiterung aus:

    ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';

    Weitere Informationen finden Sie unter Aktualisierung von SQL Postgre-Erweiterungen RDS für SQL Postgre-Datenbanken. Weitere Informationen zur Aktualisierung von Post GIS finden Sie unterSchritt 6: Aktualisieren Sie die GIS Post-Erweiterung.

  9. Entfernen bestimmter Erweiterungen vor dem Upgrade der Hauptversion – Ein Upgrade, bei dem eine Hauptversion auf Version 11.x übersprungen wird, unterstützt keine Aktualisierung der Erweiterung pgRouting. Ein Upgrade von den Versionen 9.4.x, 9.5.x oder 9.6.x auf 11.x-Versionen überspringt eine Hauptversion. Es ist sicher, die Erweiterung pgRouting zu verwerfen zu lassen und sie nach dem Upgrade wieder auf eine kompatible Version zu installieren. Für die Erweiterungsversionen, auf die Sie aktualisieren können, lesen Sie Unterstützte SQL Postgre-Erweiterungsversionen.

    Die chkpass Erweiterungen tsearch2 und werden für SQL Postgre-Versionen 11 oder höher nicht mehr unterstützt. Wenn Sie auf Version 11.x aktualisieren, lassen Sie die Erweiterungen tsearch2 und chkpass vor dem Upgrade weg.

  10. Löschen unbekannter Datentypen – Löschen Sie unknown-Datentypen in Abhängigkeit von der Zielversion.

    SQLPostgre-Version 10 hat die Unterstützung des unknown Datentyps eingestellt. Wenn eine Datenbank der Version 9.6 den Datentyp unknown verwendet, wird bei einem Upgrade auf eine Version 10 eine Fehlermeldung wie die folgende angezeigt: 

    Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."

    Gehen Sie wie folgt vor, um den unknown Datentyp in Ihrer Datenbank zu finden, sodass Sie die fehlerhafte Spalte entfernen oder sie in einen unterstützten Datentyp ändern können: SQL

    SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

  11. Durchführen eines Upgrade-Trockenlaufs – Wir empfehlen dringend, ein Hauptversionsupgrade auf einem Duplikat Ihrer Produktionsdatenbank zu testen, bevor Sie das Upgrade auf Ihrer Produktionsdatenbank durchführen. Sie können die Ausführungspläne auf der duplizierten Testdatenbank auf mögliche Regressionen des Ausführungsplans überwachen und deren Leistung bewerten. Um eine doppelte Testinstanz zu erstellen, können Sie Ihre Datenbank entweder aus einem aktuellen Snapshot point-in-time wiederherstellen oder Ihre Datenbank auf den letzten wiederherstellbaren Zeitpunkt zurücksetzen.

    Weitere Informationen finden Sie unter Wiederherstellung aus einem Snapshot oder Wiederherstellung einer DB-Instance zu einem bestimmten Zeitpunkt für Amazon RDS. Informationen zu Multi-AZ-DB-Clustern finden Sie unter Wiederherstellen von einem Snapshot in einem Multi-AZ-DB-Cluster oder Wiederherstellen eines Multi-AZ-DB-Clusters zu einer bestimmten Zeit.

    Weitere Einzelheiten zum Durchführen des Upgrades finden Sie unter Manuelles Upgraden der Engine-Version.

    Beachten Sie beim Upgrade einer Datenbank der Version 9.6 auf Version 10, dass Postgre SQL 10 standardmäßig parallel Abfragen aktiviert. Sie können die Auswirkungen von Parallelverarbeitung vor dem Upgrade testen, indem Sie den Parameter max_parallel_workers_per_gather in Ihrer Testdatenbank auf 2 ändern.

    Anmerkung

    Der Standardwert für max_parallel_workers_per_gather-Parameter in der default.postgresql10-DB-Parametergruppe lautet 2.

    Weitere Informationen finden Sie unter Parallel Query in der Postgre-Dokumentation. SQL Um die Parallelverarbeitung in Version 10 zu deaktivieren, setzen Sie den Parameter max_parallel_workers_per_gather auf 0.

    Während des Upgrades der Hauptversion werden die Datenbanken public und template1 und das Schema public in jeder Datenbank vorübergehend umbenannt. Diese Objekte erscheinen in den Protokollen mit ihrem ursprünglichen Namen und einer zufälligen Zeichenfolge, die angehängt wird. Die Zeichenfolge wird so hinzugefügt, dass benutzerdefinierte Einstellungen wie locale und owner während des Upgrades der Hauptversion erhalten bleiben. Sobald das Upgrade abgeschlossen ist, werden die Objekte in ihre ursprünglichen Namen umbenannt.

    Anmerkung

    Während des Upgrade-Vorgangs für die Hauptversion können Sie keine point-in-time Wiederherstellung Ihrer DB-Instance oder Ihres Multi-AZ-DB-Clusters durchführen. Nachdem Amazon RDS das Upgrade durchgeführt hat, wird eine automatische Sicherung der Datenbank durchgeführt. Sie können die Zeiten vor Beginn des Upgrades und nach Abschluss der automatischen Sicherung Ihrer Datenbank point-in-time wiederherstellen.

  12. Wenn ein Upgrade aufgrund von Fehlern bei der Vorabprüfung fehlschlägt, beheben Sie die Probleme. Während des Upgrade-Vorgangs für die Hauptversion führt Amazon RDS for Postgre SQL zunächst eine Vorabprüfung durch, um alle Probleme zu identifizieren, die dazu führen könnten, dass das Upgrade fehlschlägt. Das Vorprüfverfahren überprüft alle potenziell nicht kompatiblen Bedingungen in allen Datenbanken der Instance.

    Wenn die Vorprüfung auf ein Problem stößt, wird ein Protokollereignis erstellt, das anzeigt, dass die Vorprüfung für das Upgrade fehlgeschlagen ist. Die Details des Vorprüfprozesses befinden sich in einem Upgrade-Protokoll mit dem Namen pg_upgrade_precheck.log für alle Datenbanken einer Datenbank. Amazon RDS hängt einen Zeitstempel an den Dateinamen an. Weitere Informationen zum Anzeigen von Protokollen finden Sie unter Überwachung von Amazon RDS Amazon.

    Wenn ein Lesereplikat-Upgrade bei der Vorprüfung fehlschlägt, wird die Replikation auf dem fehlgeschlagenen Lesereplikat unterbrochen und das Lesereplikat in den Status "beendet" versetzt. Löschen Sie das Lesereplikat und erstellen Sie ein neues Lesereplikat auf der Grundlage der aktualisierten primären DB-Instance.

    Beheben Sie alle im Vorprüfprotokoll identifizierten Probleme und versuchen Sie dann erneut das Hauptversionsupgrade. Im Folgenden finden Sie ein Beispiel für ein Vorprüfprotokoll.

    ------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.

* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.

* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].

* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.

  13. Wenn ein Lesereplikat-Upgrade während des Upgrades der Datenbank fehlschlägt, beheben Sie das Problem – Ein fehlgeschlagenes Lesereplikat wird in den Zustand incompatible-restore versetzt und die Replikation auf der Datenbank wird beendet. Löschen Sie das Lesereplikat und erstellen Sie ein neues Lesereplikat auf der Grundlage der aktualisierten primären DB-Instance.

    Anmerkung

    Amazon führt RDS kein Upgrade von Read Replicas für Multi-AZ-DB-Cluster durch. Wenn Sie ein Hauptversions-Upgrade auf einem Multi-AZ-DB-Cluster durchführen, ändert sich der Replikationsstatus der zugehörigen Read Replicas auf „Beendet“.

    Ein Lesereplikat-Upgrade kann aus den folgenden Gründen fehlschlagen:

    • Sie konnte die primäre DB-Instance auch nach einer Wartezeit nicht einholen.

    • Es befand sich in einem beendeten oder inkompatiblen Lebenszyklusstatus, z. B. „Speicher voll“, „Inkompatible Wiederherstellung“ usw.

    • Als das Upgrade der primären DB-Instance begann, lief auf der Lesereplikat bereits ein separates Upgrade der Unterversion.

    • Das Lesereplikat verwendete inkompatible Parameter.

    • Das Lesereplikat war nicht in der Lage, mit der primären DB-Instance zu kommunizieren, um den Datenordner zu synchronisieren.

  14. Upgrade Ihrer Produktionsdatenbank – Wenn das Upgrade der Hauptversion erfolgreich durchgeführt wurde, sollten Sie in der Lage sein, Ihre Produktionsdatenbank sicher zu aktualisieren. Weitere Informationen finden Sie unter Manuelles Upgraden der Engine-Version.

  15. Führen Sie die ANALYZE-Operation aus, um die Tabelle pg_statistic zu aktualisieren. Sie sollten dies für jede Datenbank in all Ihren SQL Postgre-Datenbanken tun. Optimizer-Statistiken werden während eines Hauptversionsupgrades nicht übertragen, daher müssen Sie alle Statistiken neu generieren, um Leistungsprobleme zu vermeiden. Führen Sie den Befehl ohne Parameter aus, um Statistiken für alle regulären Tabellen in der aktuellen Datenbank wie folgt zu generieren:

    ANALYZE VERBOSE;

    Das Flag VERBOSE ist optional, aber wenn Sie es verwenden, wird Ihnen der Fortschritt angezeigt. Weitere Informationen finden Sie ANALYZEin der Postgre-Dokumentation. SQL

    Anmerkung

    Führen Sie es nach dem Upgrade ANALYZE auf Ihrem System aus, um Leistungsprobleme zu vermeiden.

Nachdem das Upgrade der Hauptversion abgeschlossen ist, empfehlen wir Folgendes:

  • Ein SQL Postgre-Upgrade aktualisiert keine Postgre-Erweiterungen. SQL Informationen zum Upgrade von Erweiterungen finden Sie unter Aktualisierung von SQL Postgre-Erweiterungen RDS für SQL Postgre-Datenbanken.

  • Verwenden Sie optional Amazon, RDS um zwei Protokolle anzuzeigen, die das pg_upgrade Hilfsprogramm erstellt. Diese sind pg_upgrade_internal.log und pg_upgrade_server.log. Amazon RDS hängt einen Zeitstempel an den Dateinamen für diese Protokolle an. Sie können diese Protokolle wie jedes andere Protokoll einsehen. Weitere Informationen finden Sie unter Überwachung von Amazon RDS Amazon.

    Sie können die Upgrade-Protokolle auch auf Amazon CloudWatch Logs hochladen. Weitere Informationen finden Sie unter SQLPostgre-Protokolle in Amazon CloudWatch Logs veröffentlichen.

  • Um sicherzustellen, dass alles wie erwartet funktioniert, testen Sie Ihre Anwendung auf der aktualisierten Datenbank mit ähnlichem Workload. Nachdem das Upgrade bestätigt wurde, können Sie diese Testinstance löschen.