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. # Beseitigen von identifizierbaren Bereinigungsblockern in RDS für PostgreSQL Der Selbstbereinigungsprozess führt aggressive Bereinigungen durch und senkt das Alter der Transaktions-IDs auf einen Wert unterhalb des Schwellenwerts, der durch den `autovacuum_freeze_max_age`-Parameter Ihrer RDS-Instance angegeben ist. Sie können dieses Alter mit der `MaximumUsedTransactionIDs`-Metrik von Amazon CloudWatch nachverfolgen. Zum Ermitteln der Einstellung von `autovacuum_freeze_max_age` (der Standardwert ist 200 Millionen Transaktions-IDs) für Ihre Amazon-RDS-Instance eignet sich folgende Abfrage: ``` 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 Blockern aggressiver Bereinigungen sucht, wenn das Alter den Schwellenwert für die [adaptive Selbstbereinigung](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) von Amazon RDS von 500 Millionen Transaktions-IDs überschreitet. Damit `postgres_get_av_diag()` Blocker erkennt, muss der Blocker mindestens 500 Millionen Transaktionen alt sein. Die `postgres_get_av_diag()`-Funktion identifiziert die folgenden Arten von Blockern: **Topics** + [Aktive Anweisung](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement) + [Leerlauf in Transaktion](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction) + [Vorbereitete Transaktion](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction) + [Logischer Replikations-Slot](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot) + [Read Replicas](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas) + [Temporäre Tabellen](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables) ## Aktive Anweisung In PostgreSQL ist eine aktive Anweisung eine SQL-Anweisung, die aktuell von der Datenbank ausgeführt wird. Dazu gehören Abfragen, Transaktionen sowie laufende Operationen. Bei der Überwachung mit `pg_stat_activity` wird in der Statusspalte angegeben, dass der Prozess mit der entsprechenden PID aktiv ist. Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine Anweisung identifiziert, die inaktiv ist. ``` 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 Aktion** Gemäß der Empfehlung 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 Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Diese Aktion kann von einem Administrator (z. B. dem RDS-Master-Konto) oder einem Benutzer mit der erforderlichen `pg_terminate_backend()`-Berechtigung durchgeführt werden. **Warnung** Eine beendete Sitzung macht die von ihr vorgenommenen Änderungen rückgängig (`ROLLBACK`). Abhängig von Ihren Anforderungen kann es jedoch sein, dass Sie die Anweisung erneut ausführen möchten. Sie sollten dies jedoch erst tun, wenn der Selbstbereinigungsprozess die aggressive Bereinigung abgeschlossen hat. ## Leerlauf in Transaktion Eine „idle in transaction“-Anweisung bezieht sich auf jede Sitzung mit einer offenen, expliziten Transaktion (z. B. durch Ausgabe einer `BEGIN`-Anweisung), in der einige Arbeiten ausgeführt wurden und die nun darauf wartet, dass der Client entweder weitere Aufgaben übergibt oder das Ende der Transaktion durch Ausgabe von `COMMIT`, `ROLLBACK` oder `END` signalisiert (was zu einem impliziten `COMMIT` führen würde). Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, 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 Aktion** Wie in der `suggestion`-Spalte angegeben, können Sie eine Verbindung zu der Datenbank mit der „idle in transaction“-Sitzung herstellen und die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Der Benutzer kann Ihr Admin-Benutzer (RDS-Master-Konto) oder ein Benutzer mit der `pg_terminate_backend()`-Berechtigung sein. **Warnung** Eine beendete Sitzung macht die von ihr vorgenommenen Änderungen rückgängig (`ROLLBACK`). Abhängig von Ihren Anforderungen kann es jedoch sein, dass Sie die Anweisung erneut ausführen möchten. Sie sollten dies jedoch erst tun, wenn der Selbstbereinigungsprozess die aggressive Bereinigung abgeschlossen hat. ## Vorbereitete Transaktion PostgreSQL ermöglicht Transaktionen, die Teil einer zweiphasigen Commit-Strategie sind, auch bekannt als [vorbereitete Transaktionen](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). 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. Genau wie reguläre Transaktionen erhalten sie eine Transaktions-ID und können die Selbstbereinigung beeinflussen. Wenn sie im Zustand „vorbereitet“ verbleiben, kann die Selbstbereinigungsfunktion keine Einfrierungen durchführen und es kann zu einem Transaktions-ID-Wraparound kommen. Wenn Transaktionen auf unbestimmte Zeit in diesem Zustand verbleiben, ohne dass dieser von einem Transaktionsmanager aufgehoben wird, werden sie zu verwaisten vorbereiteten Transaktionen. Die einzige Möglichkeit, dieses Problem zu beheben, besteht darin, die Transaktion mit den Befehlen `COMMIT PREPARED` oder `ROLLBACK PREPARED` festzuschreiben bzw. rückgängig zu machen. **Anmerkung** Beachten Sie, dass ein Backup, das während einer vorbereiteten Transaktion erstellt wurde, diese Transaktion auch nach der Wiederherstellung noch enthält. Sehen Sie sich die folgenden Informationen genauer an, um mehr über das Finden und Beenden solcher Transaktionen zu erfahren. Die `postgres_get_av_diag()`-Funktion liefert die folgende Ausgabe, wenn sie eine vorbereitete Transaktion als Blocker identifiziert. ``` 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 Aktion** Stellen Sie, wie in der Vorschlagsspalte angegeben, eine Verbindung zu der Datenbank her, auf der sich die vorbereitete Transaktion befindet. Prüfen Sie basierend auf der `suggested_action`-Spalte sorgfältig, ob Sie entweder `COMMIT` oder ausführen `ROLLBACK` möchten und welche Aktion dann angemessen ist. Zur allgemeinen Überwachung vorbereiteter Transaktionen bietet PostgreSQL eine Katalogansicht mit der Bezeichnung `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; ``` ## Logischer Replikations-Slot Zweck eines Replikations-Slots ist es, nicht genutzte Änderungen so lange aufzubewahren, bis sie auf einen Zielserver repliziert wurden. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation unter [Logische Replikation](https://www.postgresql.org/docs/current/logical-replication.html). Es gibt zwei Arten von logischen Replikations-Slots. **Inaktive logische Replikations-Slots** Wenn die Replikation beendet wird, können nicht genutzte Transaktionsprotokolle nicht entfernt werden und der Replikations-Slot wird inaktiv. Obwohl ein inaktiver logischer Replikations-Slot derzeit nicht von einem Subscriber 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 der Selbstbereinigungsprozess interne Katalogtabellen bereinigt, da das System verhindern muss, dass LSN-Informationen überschrieben werden. Wird dieses Problem nicht behoben, kann das zu einem Aufblähen des Katalogs, zu Leistungseinbußen und zu einem erhöhten Risiko für eine Wraparound-Bereinigung führen, was wiederum Transaktionsausfallzeiten nach sich ziehen kann. **Aktive, aber langsame logische Replikations-Slots** Manchmal verzögert sich das Entfernen toter Katalog-Tupel aufgrund von Leistungseinbußen bei der logischen Replikation. Diese Verzögerung bei der Replikation verlangsamt die Aktualisierung von `catalog_xmin`und kann zu einem aufgeblähten Katalog und einer Wraparound-Bereinigung führen. Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie einen logischen Replikations-Slot als Blocker identifiziert. ``` 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 Aktion** Überprüfen Sie zur Behebung des Problems die Replikationskonfiguration auf Probleme mit dem Zielschema oder Daten, die den Anwendungsprozess möglicherweise beenden. Die häufigsten Gründe sind die folgenden: + fehlende Spalten + inkompatibler Datentyp + nicht übereinstimmende Daten + fehlende Tabelle Wenn das Problem mit Infrastrukturproblemen zusammenhängt: + Netzwerkprobleme – [Wie behebe ich Probleme mit einer Amazon-RDS-Datenbank, die sich in einem inkompatiblen Netzwerkstatus befindet?](https://repost.aws/knowledge-center/rds-incompatible-network) + Die Datenbank oder DB-Instance ist aus folgenden Gründen nicht verfügbar: + Die Replikat-Instance hat keinen Speicherplatz mehr – Sehen Sie unter [Wie behebe ich Probleme, die auftreten, wenn den Amazon-RDS-DB-Instances der Speicherplatz ausgeht?](https://repost.aws/knowledge-center/rds-out-of-storage) nach, um mehr über das Hinzufügen von Speicherplatz zu erfahren. + Incompatible-parameters – Sehen Sie unter [Wie behebe ich Fehler bei einer Amazon-RDS-DB-Instance, die im Status „incompatible-parameters“ feststeckt?](https://repost.aws/knowledge-center/rds-incompatible-parameters) nach, um mehr über die Behebung des Problems zu erfahren. Wenn sich Ihre Instance außerhalb des AWS-Netzwerks oder auf AWS-EC2 befindet, wenden Sie sich an Ihren Administrator, um zu erfahren, wie Sie die Verfügbarkeits- oder Infrastrukturprobleme lösen können. **Löschen des inaktiven Slots** **Warnung** Achtung: Vergewissern Sie sich vor dem Löschen eines Replikations-Slots, dass dieser keine laufende Replikation aufweist, inaktiv ist und sich im Zustand „nicht wiederherstellbar“ befindet. Das vorzeitige Löschen eines Slots kann zu Replikationsunterbrechungen oder Datenverlust führen. Nachdem Sie sich vergewissert haben, dass der Replikations-Slot nicht mehr benötigt wird, löschen Sie diesen, damit die Selbstbereinigung fortgesetzt werden kann. Die `active = 'f'`-Bedingung sorgt dafür, dass nur ein inaktiver Slot gelöscht wird. ``` SELECT pg_drop_replication_slot('slot1') WHERE active ='f' ``` ## Read Replicas Wenn die `hot_standby_feedback`-Einstellung für [Lesereplikate von Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md) aktiviert ist, verhindert sie, dass der Selbstbereinigungsprozess auf der primären Datenbank tote Zeilen entfernt, die möglicherweise noch von Abfragen benötigt werden, die auf dem Lesereplikat ausgeführt werden. Dies hat Auswirkungen auf alle Arten von physischen Lesereplikaten, einschließlich solcher, die mit oder ohne Replikations-Slots verwaltet werden. Dieses Verhalten ist notwendig, da Abfragen, die auf dem Standby-Replikat ausgeführt werden, erfordern, dass diese Zeilen auf der primären Datenbank verfügbar bleiben, um [Abfragekonflikte](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) und -abbrüche zu vermeiden. **Lesereplikat mit physischen Replikations-Slots** Lesereplikate mit physischen Replikations-Slots verbessern die Zuverlässigkeit und Stabilität der Replikation in RDS für PostgreSQL erheblich. Diese Slots stellen sicher, dass die primäre Datenbank wichtige Write-Ahead-Protokolldateien aufbewahrt, bis das Replikat diese verarbeitet, sodass die Datenkonsistenz auch bei Netzwerkunterbrechungen gewahrt bleibt. Ab Version 14 von RDS für PostgreSQL verwenden alle Replikate Replikations-Slots. In früheren Versionen wurden Replikations-Slots nur von regionsübergreifenden Replikaten verwendet. Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie ein Lesereplikat mit einem physischen Replikations-Slot als Blocker identifiziert. ``` blocker | Read replica with physical replication slot database | blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx wait_event | Not applicable autovacuum_lagging_by | 554,080,689 suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query: | SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377; | Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + | suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," + | [OR] + | ","Disable hot_standby_feedback"," + | [OR] + | ","Delete the read replica if not needed"} ``` **Lesereplikat mit Streaming-Replikation** Amazon RDS ermöglicht die Einrichtung von Lesereplikaten ohne physischen Replikations-Slot in älteren Versionen bis Version 13. Dieser Ansatz reduziert den Overhead, da die primäre Datenbank WAL-Dateien aggressiver recyceln kann. Dies ist in Umgebungen mit begrenztem Speicherplatz von Vorteil. Zudem kann ein gelegentlicher ReplicaLag toleriert werden. Ohne Slot muss das Standby-Replikat jedoch synchron bleiben, um zu verhindern, dass WAL-Dateien fehlen. Amazon RDS verwendet archivierte WAL-Dateien, damit das Replikat gegebenenfalls einen Rückstand aufholen kann. Dieser Vorgang ist jedoch möglicherweise langsam und erfordert eine sorgfältige Überwachung. Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie ein Streaming-Lesereplikat als Blocker identifiziert. ``` blocker | Read replica with streaming replication slot database | Not applicable blocker_identifier | xx.x.x.xxx/xx wait_event | Not applicable autovacuum_lagging_by | 610,146,760 suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: + | SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; + | Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + | suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," + | [OR] + | ","Disable hot_standby_feedback"," + | [OR] + | ","Delete the read replica if not needed"} ``` **Vorgeschlagene Aktion** Wie in der `suggested_action`-Spalte empfohlen, sollten Sie diese Optionen sorgfältig prüfen, um die Blockierung des Selbstbereinigungsprozesses aufzuheben. + **Abfrage beenden** – Gemäß der Empfehlung in der Vorschlagspalte können Sie eine Verbindung zum Lesereplikat herstellen. Laut der suggested\$1action-Spalte empfiehlt es sich jedoch, die Option zum Beenden der Sitzung sorgfältig zu prüfen. Wenn die Beendigung als sicher erachtet wird, können Sie die Sitzung mit der `pg_terminate_backend()`-Funktion beenden. Diese Aktion kann von einem Administrator (z. B. dem RDS-Master-Konto) oder einem Benutzer mit der erforderlichen pg\$1terminate\$1backend()-Berechtigung durchgeführt werden. Sie können den folgenden SQL-Befehl auf dem Lesereplikat ausführen, um die Abfrage zu beenden, die verhindert, dass der Bereinigungsprozess auf der primären Datenbank alte Zeilen löscht. Der Wert von `backend_xmin` wird in der Ausgabe der Funktion gemeldet: ``` SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = backend_xmin; ``` + **Hot-Standby-Feedback deaktivieren** – Erwägen Sie, den `hot_standby_feedback`-Parameter zu deaktivieren, wenn er zu erheblichen Verzögerungen bei der Bereinigung führt. Der `hot_standby_feedback`-Parameter ermöglicht einem Lesereplikat, die primäre Datenbank über seine Abfrageaktivität zu informieren. Dadurch wird verhindert, dass diese Tabellen entfernt, die auf dem Standby-Replikat verwendet werden. Dadurch wird zwar die Stabilität der Abfrage auf diesem gewährleistet, die Bereinigung auf der primären Datenbank kann sich jedoch erheblich verzögern. Wenn Sie diese Funktion deaktivieren, kann die Bereinigung auf der primären Datenbank fortgesetzt werden, ohne dass darauf gewartet werden muss, dass das Standby-Replikat aufholt. Dies kann jedoch zu Abfrageabbrüchen oder -fehlern auf dem Standby-Replikat führen, wenn versucht wird, auf Zeilen zuzugreifen, die auf der primären Datenbank bereinigt wurden. + **Nicht benötigtes Lesereplikat löschen** – Wenn das Lesereplikat nicht mehr benötigt wird, können Sie es löschen. Dadurch entfällt der damit verbundene Replikations-Overhead und ermöglicht das Recyclen von Transaktionsprotokollen auf der primären Datenbank, ohne vom Replikat zurückgehalten zu werden. ## Temporäre Tabellen [Temporäre Tabellen](https://www.postgresql.org/docs/current/sql-createtable.html), die mit dem `TEMPORARY`-Schlüsselwort erstellt wurden, befinden sich im temporären Schema, z. B. in pg\$1temp\$1xxx, 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 Selbstbereinigungsprozess von PostgreSQL unsichtbar und müssen manuell von der Sitzung bereinigt werden, von der sie erstellt wurden. Der Versuch, die temporäre Tabelle von einer anderen Sitzung aus bereinigen zu lassen, hat keine Wirkung. In seltenen Fällen kann es eine temporäre Tabelle geben, die keiner aktiven Sitzung angehört. Wenn die innehabende Sitzung 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 Selbstbereinigungsprozess von PostgreSQL eine solche verwaiste temporäre Tabelle entdeckt, protokolliert er die folgende Meldung: ``` LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\" ``` Die `postgres_get_av_diag()`-Funktion liefert eine Ausgabe ähnlich der folgenden, wenn sie eine temporäre Tabelle als Blocker identifiziert. Damit die Funktion die Ausgabe in Bezug auf temporäre Tabellen korrekt anzeigt, muss sie auf der Datenbank ausgeführt werden, auf der diese Tabellen vorhanden sind. ``` 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 Aktion** Folgen Sie den Anleitungen aus der `suggestion`-Spalte der Ausgabe, um die temporäre Tabelle zu identifizieren und zu entfernen, die die Ausführung des Selbstbereinigungsprozesses 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 gelieferten Ausgabe. ``` DROP TABLE my_temp_schema.my_temp_table; ``` Mit der folgenden Abfrage können temporäre Tabellen identifiziert werden: ``` SELECT oid, relname, relnamespace::regnamespace, age(relfrozenxid) FROM pg_class WHERE relpersistence = 't' ORDER BY age(relfrozenxid) DESC; ```