Lösung nicht identifizierbarer Vakuumblocker für Postgre RDS SQL

In diesem Abschnitt werden weitere Gründe untersucht, die verhindern können, dass das Staubsaugen voranschreitet. Diese Probleme sind derzeit anhand der Funktion nicht direkt identifizierbar. postgres_get_av_diag()

Ungültige Seiten

Ein ungültiger Seitenfehler tritt auf, wenn Postgre beim Zugriff auf diese Seite eine Nichtübereinstimmung in der Prüfsumme einer Seite SQL feststellt. Der Inhalt ist nicht lesbar, wodurch das automatische Vakuumieren verhindert, dass Tupel eingefroren werden. Dadurch wird der Säuberungsvorgang effektiv gestoppt. Der folgende Fehler wird in das Protokoll von Postgre SQL geschrieben:

WARNING:  page verification failed, calculated checksum YYYYY but expected XXXX
ERROR:  invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT:  automatic vacuum of table myschema.mytable

Ermitteln Sie den Objekttyp

ERROR: invalid page in block 4305910 of relation base/16403/186752608 
WARNING: page verification failed, calculated checksum 50065 but expected 60033

Aus der Fehlermeldung geht hervor, dass der Pfad die folgenden Informationen base/16403/186752608 enthält:

• „base“ ist der Verzeichnisname unter dem SQL Postgre-Datenverzeichnis.

• „16403" ist die DatenbankOID, die Sie im Systemkatalog nachschlagen können. pg_database

• „186752608“ ist dierelfilenode, mit der Sie das Schema und den Objektnamen im Systemkatalog nachschlagen können. pg_class

Indem Sie die Ausgabe der folgenden Abfrage in der betroffenen Datenbank überprüfen, können Sie den Objekttyp ermitteln. Die folgende Abfrage ruft Objektinformationen für oid ab: 186752608. Ersetzen Sie das durch das, OID was für den Fehler relevant ist, auf den Sie gestoßen sind.

SELECT
    relname AS object_name,
    relkind AS object_type,
    nspname AS schema_name
FROM
    pg_class c
    JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
    c.oid = 186752608;

Weitere Informationen finden Sie in der SQL Postgre-Dokumentation pg_classfür alle unterstützten Objekttypen, die in pg_class der relkind Spalte unter aufgeführt sind.

Anleitung

Die effektivste Lösung für dieses Problem hängt von der Konfiguration Ihrer spezifischen RDS Amazon-Instance und der Art der Daten ab, die von der inkonsistenten Seite betroffen sind.

Wenn der Objekttyp ein Index ist:

Es wird empfohlen, den Index neu zu erstellen.

• Verwenden der CONCURRENTLY Option — Vor SQL Postgre-Version 12 erforderte die Neuerstellung eines Indexes eine exklusive Tabellensperre, die den Zugriff auf die Tabelle einschränkte. In SQL Postgre-Version 12 und späteren Versionen ermöglicht CONCURRENTLY diese Option das Sperren auf Zeilenebene, wodurch die Verfügbarkeit der Tabelle erheblich verbessert wird. Es folgt der Befehl:

  REINDEX INDEX ix_name CONCURRENTLY;

  Er CONCURRENTLY ist zwar weniger störend, kann aber bei stark frequentierten Tabellen langsamer sein. Erwägen Sie, den Index nach Möglichkeit in Zeiten mit geringem Datenverkehr zu erstellen.

  Weitere Informationen finden Sie in der Postgre-Dokumentation. SQL REINDEX

• Verwenden Sie die INDEX_CLEANUP FALSE Option — Wenn die Indizes umfangreich sind und schätzungsweise viel Zeit benötigen, bis sie fertig sind, können Sie die automatische Bereinigung aufheben, indem Sie ein manuelles Verfahren ausführen VACUUM FREEZE und dabei Indizes ausschließen. Diese Funktionalität ist in SQL Postgre-Version 12 und späteren Versionen verfügbar.

  Durch das Umgehen von Indizes können Sie den Vakuumprozess des inkonsistenten Indexes überspringen und das Wraparound-Problem verringern. Das zugrundeliegende Problem mit ungültigen Seiten wird dadurch jedoch nicht gelöst. Um das Problem mit der ungültigen Seite vollständig zu beheben und zu lösen, müssen Sie den Index dennoch neu erstellen.

Wenn es sich bei dem Objekttyp um eine materialisierte Ansicht handelt:

Wenn in einer materialisierten Ansicht ein ungültiger Seitenfehler auftritt, melden Sie sich bei der betroffenen Datenbank an und aktualisieren Sie sie, um die ungültige Seite zu beheben:

Aktualisieren Sie die materialisierte Ansicht:

REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;

Wenn die Aktualisierung fehlschlägt, versuchen Sie, Folgendes neu zu erstellen:

DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;

Durch das Aktualisieren oder Neuerstellen der materialisierten Ansicht wird sie wiederhergestellt, ohne dass sich dies auf die zugrunde liegenden Tabellendaten auswirkt.

Für alle anderen Objekttypen:

Für alle anderen Objekttypen wenden Sie sich an den AWS Support.

Inkonsistenz im Index

Ein logisch inkonsistenter Index kann verhindern, dass das Autovakuumverfahren voranschreitet. Die folgenden oder ähnliche Fehler werden entweder während der Vakuumphase des Index oder beim Zugriff auf den Index durch Anweisungen protokolliert. SQL

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

Leitlinien

Erstellen Sie den Index manuell VACUUM FREEZE neu oder überspringen Sie INDEX_CLEANUP Indizes. Informationen zur Neuerstellung des Index finden Sie unter Wenn der Objekttyp ein Index ist.

Außergewöhnlich hohe Transaktionsrate

In Postgre SQL können hohe Transaktionsraten die Leistung von Autovacuum erheblich beeinträchtigen, was zu einer langsameren Bereinigung toter Tupel und einem erhöhten Risiko eines Transaktions-ID-Wraparounds führt. Sie können die Transaktionsrate überwachen, indem Sie den Unterschied max(age(datfrozenxid)) zwischen zwei Zeiträumen messen, typischerweise pro Sekunde. Darüber hinaus können Sie die folgenden Zählermetriken von RDS Performance Insights verwenden, um die Transaktionsrate (die Summe aus xact_commit und xact_rollback) zu messen, die die Gesamtzahl der Transaktionen darstellt.

Zähler	Typ	Einheit	Metrik
xact_commit	Transaktionen	Commits pro Sekunde	db.Transactions.xact_commit
xact_rollback	Transaktionen	Rollbacks pro Sekunde	db.Transactions.xact_rollback

Ein schneller Anstieg deutet auf eine hohe Transaktionslast hin, die Autovacuum überfordern und zu Blähungen, Sperrkonflikten und potenziellen Leistungsproblemen führen kann. Dies kann sich auf verschiedene Weise negativ auf den Autovakuumprozess auswirken:

• Tabellenaktivität: Bei der spezifischen Tabelle, die gelöscht wird, kann es zu einem hohen Transaktionsvolumen kommen, was zu Verzögerungen führen kann.

• Systemressourcen Das gesamte System ist möglicherweise überlastet, sodass es für Autovacuum schwierig ist, auf die Ressourcen zuzugreifen, die für einen effizienten Betrieb erforderlich sind.

Ziehen Sie die folgenden Strategien in Betracht, damit das Autovakuumgerät effektiver arbeiten und seine Aufgaben erfüllen kann:

1. Reduzieren Sie nach Möglichkeit die Transaktionsrate. Erwägen Sie, ähnliche Transaktionen nach Möglichkeit zu stapeln oder zu gruppieren.

2. Nehmen Sie häufig aktualisierte Tabellen ins Visier und VACUUM FREEZE verwenden Sie sie nachts, wöchentlich oder zweiwöchentlich außerhalb der Spitzenzeiten manuell.

3. Erwägen Sie, Ihre Instance-Klasse zu skalieren, um mehr Systemressourcen für das hohe Transaktionsvolumen und die automatische Bereinigung bereitzustellen.