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.

Lösung identifizierbarer Vakuumblocker in

Autovacuum führt aggressive Löschvorgänge durch und senkt das Alter der Transaktion auf einen Wert unter den durch den Parameter Ihrer IDs RDS-Instance angegebenen Schwellenwert. autovacuum_freeze_max_age Sie können dieses Alter anhand der CloudWatch Amazon-Metrik verfolgenMaximumUsedTransactionIDs.

Um die Einstellung von autovacuum_freeze_max_age (die standardmäßig 200 Millionen Transaktionen hat IDs) für Ihre Amazon RDS-Instance zu ermitteln, können Sie die folgende Abfrage verwenden:

SELECT
    TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
    pg_settings
WHERE
    name = 'autovacuum_freeze_max_age';

Beachten Sie, dass postgres_get_av_diag() nur dann nach aggressiven Vakuumblockern gesucht wird, wenn das Alter den adaptiven Autovakuum-Schwellenwert von Amazon RDS von 500 Millionen Transaktionen überschreitet. IDs postgres_get_av_diag()Um Blocker zu erkennen, muss der Blocker mindestens 500 Millionen Transaktionen alt sein.

Die postgres_get_av_diag() Funktion identifiziert die folgenden Arten von Blockern:

Aktive Aussage

In PostgreSQL ist eine aktive Anweisung eine SQL-Anweisung, die gerade von der Datenbank ausgeführt wird. Dazu gehören Abfragen, Transaktionen oder alle laufenden Operationen. Bei der Überwachung über pg_stat_activity gibt die Statusspalte an, dass der Prozess mit der entsprechenden PID aktiv ist.

Die postgres_get_av_diag() Funktion zeigt eine Ausgabe ähnlich der folgenden an, wenn sie eine Anweisung identifiziert, bei der es sich um eine aktive Anweisung handelt.

blocker               | Active statement
database              | my_database
blocker_identifier    | SELECT pg_sleep(20000);
wait_event            | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion            | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"SELECT pg_terminate_backend (29621);"}

Vorgeschlagene Maßnahme

Gemäß den Anweisungen in der suggestion Spalte kann der Benutzer eine Verbindung zu der Datenbank herstellen, in der sich die aktive Anweisung befindet. Wie in der suggested_action Spalte angegeben, ist es ratsam, die Option zum Beenden der Sitzung sorgfältig zu prüfen. Wenn die Beendigung sicher ist, können Sie die pg_terminate_backend() Funktion verwenden, um die Sitzung zu beenden. Diese Aktion kann von einem Administrator (z. B. dem RDS-Hauptkonto) oder einem Benutzer mit den erforderlichen Rechten ausgeführt pg_terminate_backend() werden.

Leerlauf in Transaktion

Eine Idle in Transaction-Anweisung bezieht sich auf jede Sitzung, die eine explizite Transaktion geöffnet hat (z. B. durch Ausgabe einer BEGIN Anweisung), einige Arbeiten ausgeführt hat und nun darauf wartet, dass der Client entweder weitere Aufgaben weitergibt oder das Ende der Transaktion durch Ausgabe einesCOMMIT,ROLLBACK, oder signalisiert END (was zu einem impliziten COMMIT Ergebnis führen würde).

Die postgres_get_av_diag() Funktion zeigt eine Ausgabe an, die der folgenden ähnelt, wenn sie eine idle in transaction Anweisung als Blocker identifiziert.

blocker               | idle in transaction
database              | my_database
blocker_identifier    | INSERT INTO tt SELECT * FROM tt;
wait_event            | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion            | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"SELECT pg_terminate_backend (28438);"}

Vorgeschlagene Maßnahme

Wie in der suggestion Spalte angegeben, können Sie eine Verbindung zu der Datenbank herstellen, in der sich die inaktive Transaktionssitzung befindet, und die Sitzung mithilfe der pg_terminate_backend() Funktion beenden. Der Benutzer kann Ihr Admin-Benutzer (RDS-Hauptkonto) oder ein Benutzer mit der entsprechenden pg_terminate_backend() Berechtigung sein.

Vorbereitete Transaktion

PostgreSQL ermöglicht Transaktionen, die Teil einer zweiphasigen Commit-Strategie sind, die als vorbereitete Transaktionen bezeichnet werden. Diese werden aktiviert, indem der max_prepared_transactions Parameter auf einen Wert ungleich Null gesetzt wird. Vorbereitete Transaktionen sollen sicherstellen, dass eine Transaktion dauerhaft ist und auch nach Datenbankabstürzen, Neustarts oder Verbindungsabbrüchen des Clients verfügbar bleibt. Wie bei normalen Transaktionen wird ihnen eine Transaktions-ID zugewiesen, was sich auf das Autovakuum auswirken kann. In einem vorbereiteten Zustand kann Autovacuum das Einfrieren nicht durchführen und es kann zu einem Umbruch der Transaktions-ID kommen.

Wenn Transaktionen auf unbestimmte Zeit vorbereitet bleiben, ohne von einem Transaktionsmanager bearbeitet zu werden, werden sie zu verwaisten vorbereiteten Transaktionen. Die einzige Möglichkeit, dies zu beheben, besteht darin, die Transaktion mit den ROLLBACK PREPARED Befehlen oder festzuschreiben COMMIT PREPARED oder rückgängig zu machen.

Die postgres_get_av_diag() Funktion zeigt die folgende Ausgabe an, wenn sie einen Blocker identifiziert, bei dem es sich um eine vorbereitete Transaktion handelt.

blocker               | Prepared transaction
database              | my_database
blocker_identifier    | myptx
wait_event            | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion            | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}

Vorgeschlagene Maßnahme

Stellen Sie, wie in der Spalte mit den Vorschlägen erwähnt, eine Verbindung zu der Datenbank her, in der sich die vorbereitete Transaktion befindet. Prüfen Sie anhand der suggested_action Spalte sorgfältig, ob Sie entweder COMMIT oder ausführen ROLLBACK möchten und welche Aktion dann angemessen ist.

Um vorbereitete Transaktionen generell zu überwachen, bietet PostgreSQL eine Katalogansicht namens. pg_prepared_xacts Sie können die folgende Abfrage verwenden, um vorbereitete Transaktionen zu finden.

SELECT
    gid,
    prepared,
    owner,
    database,
    transaction AS oldest_xmin
FROM
    pg_prepared_xacts
ORDER BY
    age(transaction) DESC;

Steckplatz für logische Replikation

Der Zweck eines Replikationsslots besteht darin, nicht verbrauchte Änderungen so lange aufzubewahren, bis sie auf einen Zielserver repliziert wurden. Weitere Informationen finden Sie unter Logische Replikation von PostgreSQL.

Es gibt zwei Arten von Steckplätzen für logische Replikation.

Inaktive Steckplätze für logische Replikation

Wenn die Replikation beendet wird, können nicht verbrauchte Transaktionsprotokolle nicht entfernt werden, und der Replikationssteckplatz wird inaktiv. Obwohl ein inaktiver logischer Replikationssteckplatz derzeit nicht von einem Abonnenten verwendet wird, verbleibt er auf dem Server, was zur Aufbewahrung von WAL-Dateien führt und verhindert, dass alte Transaktionsprotokolle entfernt werden. Dies kann die Festplattennutzung erhöhen und insbesondere verhindern, dass Autovacuum interne Katalogtabellen bereinigt, da das System verhindern muss, dass LSN-Informationen überschrieben werden. Wenn dieses Problem nicht behoben wird, kann dies zu einer Überlastung des Katalogs, zu Leistungseinbußen und einem erhöhten Risiko eines unvollständigen Speichers führen, was wiederum zu Transaktionsausfällen führen kann.

Aktive, aber langsame Steckplätze für logische Replikation

Manchmal verzögert sich das Entfernen toter Katalogtupel aufgrund von Leistungseinbußen bei der logischen Replikation. Diese Verzögerung bei der Replikation verlangsamt die Aktualisierung des Systems catalog_xmin und kann zu einer Überlastung des Katalogs und zu einem vollständigen Vakuum führen.

Die postgres_get_av_diag() Funktion zeigt eine Ausgabe ähnlich der folgenden an, wenn sie einen logischen Replikationsslot als Blocker findet.

blocker               | Logical replication slot
database              | my_database
blocker_identifier    | slot1
wait_event            | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion            | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}

Vorgeschlagene Maßnahme

Um dieses Problem zu beheben, überprüfen Sie die Replikationskonfiguration auf Probleme mit dem Zielschema oder den Daten, die den Anwenden-Prozess möglicherweise beenden könnten. Die häufigsten Gründe sind die folgenden:

Wenn das Problem mit Infrastrukturproblemen zusammenhängt:

Wenn sich Ihre Instance außerhalb des AWS Netzwerks oder in Betrieb befindet AWS EC2, wenden Sie sich an Ihren Administrator, um zu erfahren, wie Sie die Verfügbarkeits- oder Infrastrukturprobleme lösen können.

Den inaktiven Slot löschen

Nachdem Sie sich vergewissert haben, dass der Replikationssteckplatz nicht mehr benötigt wird, löschen Sie ihn, damit die automatische Bereinigung fortgesetzt werden kann. Diese Bedingung active = 'f' stellt sicher, dass nur ein inaktiver Steckplatz gelöscht wird.

SELECT pg_drop_replication_slot('slot1') WHERE active ='f'

Reader-Instanzen

Wenn die Einstellung hot_standby_feedback aktiviert ist, verhindert sie, dass Autovacuum auf der Writer-Instanz tote Zeilen entfernt, die möglicherweise noch von Abfragen benötigt werden, die auf der Reader-Instanz ausgeführt werden. Dieses Verhalten ist notwendig, da Abfragen, die auf der Reader-Instance ausgeführt werden (gilt auch für Reader-Instances in Aurora Global Database), erfordern, dass diese Zeilen auf der Writer-Instance verfügbar bleiben, um Abfragekonflikte und Abbrüche zu vermeiden.

Die postgres_get_av_diag() Funktion zeigt eine Ausgabe ähnlich der folgenden an, wenn sie eine Read Replica mit einem physischen Replikationssteckplatz als Blocker findet.

blocker               | Oldest query running on aurora reader
database              | Not applicable
blocker_identifier    | my-aurora-reader-2
wait_event            | Not applicable
autovacuum_lagging_by | 540,122,859
suggestion            | Run the following query on the reader "my-aurora-reader-2" to find the long running query:                                                                                                 
                      | SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 523476310;                                                                                                    
                      | Review carefully and you may consider terminating the query on reader using suggested_action.                                                      
suggested_action      | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 523476310;","                                                                       
                      | [OR]                                                                                                                                                                                    
                      | ","Delete the reader if not needed"}

Wie in der suggested_action Spalte empfohlen, sollten Sie diese Optionen sorgfältig prüfen, um die automatische Vakuumierung zu entsperren.

Temporäre Tabellen

Temporäre Tabellen, die mit dem TEMPORARY Schlüsselwort erstellt wurden, befinden sich im temporären Schema, z. B. pg_temp_xxx, und sind nur für die Sitzung zugänglich, in der sie erstellt wurden. Temporäre Tabellen werden gelöscht, wenn die Sitzung endet. Diese Tabellen sind jedoch für den Autovacuum-Prozess von PostgreSQL unsichtbar und müssen von der Sitzung, in der sie erstellt wurden, manuell gelöscht werden. Der Versuch, die temporäre Tabelle aus einer anderen Sitzung zu löschen, hat keine Wirkung.

Unter ungewöhnlichen Umständen ist eine temporäre Tabelle vorhanden, ohne dass sie einer aktiven Sitzung gehört. Wenn die Eigentümersitzung aufgrund eines fatalen Absturzes, eines Netzwerkproblems oder eines ähnlichen Ereignisses unerwartet beendet wird, wird die temporäre Tabelle möglicherweise nicht bereinigt, sodass sie als „verwaiste“ Tabelle zurückbleibt. Wenn der PostgreSQL-Autovacuum-Prozess eine verwaiste temporäre Tabelle erkennt, protokolliert er die folgende Meldung:

LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"

Die postgres_get_av_diag() Funktion zeigt eine Ausgabe ähnlich der folgenden an, wenn sie eine temporäre Tabelle als Blocker identifiziert. Damit die Funktion die Ausgabe in Bezug auf temporäre Tabellen korrekt anzeigt, muss sie in derselben Datenbank ausgeführt werden, in der diese Tabellen existieren.

blocker               | Temporary table
database              | my_database
blocker_identifier    | pg_temp_14.ttemp
wait_event            | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion            | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"DROP TABLE ttemp;"}

Vorgeschlagene Maßnahme

Folgen Sie den Anweisungen in der suggestion Spalte der Ausgabe, um die temporäre Tabelle zu identifizieren und zu entfernen, die das Ausführen von Autovacuum verhindert. Verwenden Sie den folgenden Befehl, um die temporäre Tabelle zu löschen, die von postgres_get_av_diag() gemeldet wurde. Ersetzen Sie den Tabellennamen auf der Grundlage der von der postgres_get_av_diag() Funktion bereitgestellten Ausgabe.

DROP TABLE my_temp_schema.my_temp_table;

Die folgende Abfrage kann verwendet werden, um temporäre Tabellen zu identifizieren:

SELECT
    oid,
    relname,
    relnamespace::regnamespace,
    age(relfrozenxid)
FROM
    pg_class
WHERE
relpersistence = 't'
ORDER BY
    age(relfrozenxid) DESC;