Wie behebe ich Probleme mit der Transaktions-ID-Wraparound in Aurora PostgreSQL-Compatible?

Lösung

Überwachen von Metriken und CloudWatch-Alarmen, um Probleme zu vermeiden

Um das Alter der ältesten nicht bereinigten Transaktion zu überwachen, überprüfe die MaximumUsedTransactionIDs-Metrik in Amazon CloudWatch. Erstelle einen CloudWatch-Alarm, um Probleme mit der Transaktions-ID zu vermeiden. Weitere Informationen findest du unter Implementieren eines Frühwarnsystems für Transaktions-ID-Wraparound in Amazon Relational Database Service (Amazon RDS) für PostgreSQL.

Diagnoseabfragen ausführen

Verwende psql oder pgAdmin, um eine Verbindung zur PostgreSQL-DB-Instance herzustellen.

Führe den folgenden Befehl aus, um das Datenbankalter zu überprüfen:

SELECT datname, age(datfrozenxid)
FROM pg_database
ORDER BY 2 DESC
LIMIT 20;

Hinweis: Wenn die Ausgabe zeigt, dass die rdsadmin- oder template0-Datenbank das älteste Transaktions-ID-Alter hat, wende dich an den AWS Support.

Führe den folgenden Befehl aus, um eine Verbindung mit der Datenbank mit dem höchsten Alter herzustellen und potenzielle Probleme mit Tabellen zu identifizieren:

SELECT
c.relnamespace::regnamespace as schema_name,
c.oid::regclass as table_name,
greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
t.relkind, t.relpersistence
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm')
ORDER BY 3 DESC
LIMIT 20;

Führe den folgenden Befehl aus, um den automatischen Bereinigungsverlauf von Tabellen mit hohen Alterswerten zu überprüfen:

SELECT
  relname,
  n_live_tup, n_tup_upd, n_tup_del, n_dead_tup,
  last_vacuum, last_autovacuum,
  last_analyze, last_autoanalyze
FROM pg_stat_user_tables
WHERE relname='table_name';

Hinweis: Ersetze table_name durch deinen Tabellennamen.

Führe den folgenden Befehl aus, um den aktiven Bereinigungsvorgang zu überwachen:

SELECT datname, usename, pid, state, wait_event,
current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
AND pid <> pg_backend_pid()
ORDER BY xact_start;

Blockaden im automatischen Bereinigungsprozess beheben

Wenn du eine der folgenden Versionen von Aurora PostgreSQL-Compatible verwendest, findest du weitere Informationen unter Identifizieren und Beheben aggressiver Bereinigungsblockaden in Aurora PostgreSQL:

• 13.19 oder später
• 14.16 oder später
• 15.11 oder später
• 16.7 oder später
• 17.2 oder später

Transaktionen mit langer Laufzeit beheben

Transaktionen mit langer Laufzeit oder Übergangssitzungen, die inaktiv sind, können die automatische Bereinigung blockieren. 

In den PostgreSQL-Fehlerprotokollen wird die folgende Warnmeldung angezeigt:

„WARNING: oldest xmin is far in the past HINT: Close open transactions soon to avoid wraparound problems.“

Führe den folgenden Befehl aus, um Transaktionen zu identifizieren, die die automatische Bereinigung blockieren:

SELECT pid,
    age(backend_xid),
    substr(query,1,20),
    extract(epoch from now()) - extract(epoch from xact_start) as duration,
    state
FROM pg_stat_activity
WHERE xact_start is not null
AND age(backend_xid) is not null
ORDER BY 2 DESC
LIMIT 10;

Um dieses Problem zu beheben, kannst du entweder aktive Abfragen abbrechen oder Verbindungen beenden.

Führe den folgenden Befehl aus, um aktive Abfragen abzubrechen:

SELECT pg_cancel_backend(pid);

Hinweis: Ersetze pid durch die Prozess-ID aus den Abfrageergebnissen.

Führe den folgenden Befehl aus, um Verbindungen zu beenden:

SELECT pg_terminate_backend(pid);

Hinweis: Ersetze pid durch die Prozess-ID aus den Abfrageergebnissen.

Um sicherzustellen, dass Transaktionen mit langer Laufzeit die automatische Bereinigung nicht erneut blockieren, lege die Parameter statement_timeout, idle_in_transaction_session_timeout und log_min_duration_statement fest.

Inaktive logische Replikations-Slots auflösen

Führe den folgenden Befehl aus, um inaktive Slots zu identifizieren:

SELECT slot_name, slot_type, database, xmin, catalog_xmin,
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS replicationSlotLag,
    active
FROM pg_replication_slots
ORDER BY age(xmin), age(catalog_xmin) DESC;

Warnung: Bevor du einen Replikations-Slot löschst, vergewissere dich, dass keine laufende Replikation stattfindet, dass er inaktiv ist und sich in einem Zustand befindet, der nicht wiederhergestellt werden kann. Wenn du einen Slot löschst, der immer noch repliziert, aktiv und wiederherstellbar ist, kann dies zu einer Unterbrechung der Replikation oder zu Datenverlust führen.

Führe den folgenden Befehl aus, um ungenutzte Slots zu löschen:

SELECT pg_drop_replication_slot('slot_name');

Hinweis: Ersetze slot_name durch den Namen deines Replikations-Slots.

Probleme mit der Reader-Instance beheben

Führe die folgende Abfrage aus, um Reader in einem Aurora-Cluster zu identifizieren, die möglicherweise Hot-Standby-Feedback verhindern und die automatische Bereinigung blockieren:

select server_id, feedback_epoch, feedback_xmin
from aurora_replica_status()
WHERE (feedback_xmin IS NOT NULL AND feedback_xmin > 0)

Führe die folgende Abfrage für Reader aus, die Hot-Standby-Feedback in globalen Datenbankclustern verhindern:

select server_id,aws_region,feedback_epoch,feedback_xmin
from aurora_global_db_instance_status ()
WHERE (feedback_xmin IS NOT NULL AND feedback_xmin > 0);

Führe die folgende Abfrage in den Reader-Instances mit dem niedrigsten kombinierten Wert von feedback_epoch und feedback_xmin aus:

SELECT pid,
    age(backend_xid),
    substr(query,1,20),
    extract(epoch from now()) - extract(epoch from xact_start) as duration,
    state
FROM pg_stat_activity WHERE backend_xmin::text::bigint =feedback_xmin

Hinweis: Ersetze feedback_xmin durch den feedback_xmin-Wert aus den vorherigen Abfrageergebnissen.

Wenn du dies sicher tun kannst, verwende pg_terminate_backend(pid), um die Transaktionen mit langer Laufzeit zu beenden.

Nicht festgeschriebene vorbereitete Transaktionen auflösen

Führe den folgenden Befehl aus, um vorbereitete Transaktionen zu identifizieren:

SELECT database, gid, prepared, owner, database, transaction::text::bigint as xid,
now() - prepared AS time_since_prepared
FROM pg_prepared_xacts
ORDER BY age(transaction) DESC;

Um vorbereitete Transaktionen aufzulösen, kannst du die vorbereitete Transaktion entweder committen oder zurücksetzen.

Führe den folgenden Befehl aus, um die vorbereitete Transaktion zu committen:

COMMIT PREPARED 'gid'

Hinweis: Ersetze gid durch die globale Transaktions-ID aus den Abfrageergebnissen.

Warnung: Bevor du eine vorbereitete Transaktion zurücksetzt, stelle sicher, dass die Transaktion nicht Teil einer verteilten Transaktionssequenz ist.

Führe den folgenden Befehl aus, um die vorbereitete Transaktion zurückzusetzen:

ROLLBACK PREPARED 'gid'

Hinweis: Ersetze gid durch die globale Transaktions-ID aus den Abfrageergebnissen.

Verwaiste temporäre Tabellen auflösen

Wenn der automatische PostgreSQL-Bereinigungsprozess auf verwaiste temporäre Tabellen trifft, protokolliert er das folgende Ereignis:

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

Führe den folgenden Befehl aus, um verwaiste temporäre Tabellen zu identifizieren:

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

Führe den folgenden Befehl aus, um die temporäre Tabelle zu löschen:

DROP TABLE temporary_table

Hinweis: Ersetzetemporary_table durch den Namen deiner temporären Tabelle.

Probleme mit der Bereinigungsleistung lösen

Wenn die automatische Bereinigung langsam durchgeführt wird, kann es zu Verzögerungen beim Einfriervorgang kommen.

Um dieses Problem zu beheben, erhöhe zunächst den Parameter autovacuum_max_workers für mehrere gleichzeitige Bereinigungsvorgänge. Verwende dann die folgende Formel, um den Parameter autovacuum_vacuum_cost_limit gleichmäßig zu erhöhen:

Individual worker's cost_limit = autovacuum_vacuum_cost_limit / autovacuum_max_workers

Wenn die Bereinigungsleistung nach dem Erhöhen der Parameter weiterhin unzureichend ist, aktualisiere die Amazon-RDS-Instance auf eine Klasse mit mehr vCPUs. Du kannst den Parameter autovacuum_vacuum_cost_delay auf Tabellenebene ändern, um automatische Bereinigungsvorgänge zu beschleunigen.

Führe den folgenden Befehl aus, um den Parameter autovacuum_vacuum_cost_delay auf Tabellenebene zu ändern:

ALTER TABLE mytable SET ( autovacuum_vacuum_cost_delay = value, autovacuum_vacuum_cost_limit = value );

Hinweis: Ersetze mytable durch deinen Tabellennamen und value durch deine gewünschten Parameterwerte.

Bereinigungsleistung bei großen Indizes

Wenn du große Indizes bereinigst, können Speicherbeschränkungen mehrere Durchgänge über denselben Index erzwingen und die VACUUM-Gesamtdauer erheblich verlängern.

Wenn in PostgreSQL 16 oder früher langsame VACUUM-Vorgänge an großen Indizes auftreten, suche nach den folgenden möglichen Ursachen:

• Die Indexgröße überschreitet 1 GB.
• Es finden mehrere VACUUM-Durchgänge statt. Um die Anzahl der Durchgänge anzuzeigen, frage die index_vacuum_count in der Ansicht pg_stat_progress_vacuum ab.
• Du hast maintenance_work_mem oder autovacuum_work_mem falsch konfiguriert.

Gehe wie folgt vor, um dieses Problem zu beheben:

• Lösche unbenutzte oder doppelte Indizes.
• Erhöhe maintenance_work_mem oder autovacuum_work_mem. Damit die neue Speichereinstellung wirksam wird, beende die Prozesse, die gerade die automatische Bereinigung ausführen.
• Führe manuell einen VACUUM FREEZE-Vorgang durch und erhöhe maintenance_work_mem innerhalb der Sitzung.

Wenn du PostgreSQL Version 12 oder höher verwendest, führe den folgenden Befehl aus, um mögliche manuelle Bereinigungen mit Indexausschlüssen zu überprüfen:

VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;

Hinweis: Ersetze table_name durch deinen Tabellennamen.

Logische Inkonsistenz

Wenn ein logisch inkonsistenter Index den automatischen Bereinigungsprozess blockiert, erhältst du möglicherweise eine der folgenden Fehlermeldungen:

• ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
• ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX CONTEXT: while vacuuming index index_name of relation schema.table

Um dieses Problem zu beheben, erstelle den Index neu. Bei PostgreSQL-Versionen 12 und höher kannst du die Indexbereinigung überspringen.

Führe den folgenden Befehl aus, um den Index neu zu erstellen:

REINDEX INDEX ix_name CONCURRENTLY;

Hinweis: Ersetze ix_name durch deinen Indexnamen.

-oder-

Führe den folgenden Befehl aus. um die Indexbereinigung für PostgreSQL 12 und höher zu überspringen:

VACUUM FREEZE INDEX_CLEANUP FALSE table_name;

Hinweis: Ersetze table_name durch deinen Tabellennamen.

Ähnliche Informationen

Preventing transaction ID wraparound failures (Verhinderung von Transaktions-ID-Wraparound-Fehlern) auf der PostgreSQL-Website

Arbeiten mit der automatischen PostgreSQL-Bereinigung auf Amazon Aurora PostgreSQL

Grundlegendes zum automatischen Bereinigen in Umgebungen von Amazon RDS für PostgreSQL

Wie beende ich Abfragen mit langer Laufzeit in meiner DB-Instance von Amazon RDS für PostgreSQL oder Aurora PostgreSQL-Compatible?