Verwaltung hoher Objektzahlen in

Autovacuum kann Schwierigkeiten haben, mit dem Wachstum der Transaktions-IDs Schritt zu halten, oder es kann sein, dass die Tabelle aufgrund des Mangels an Mitarbeitern im Verhältnis zum Arbeitsaufwand überfüllt wird.

Empfohlene Maßnahme: Es gibt mehrere Faktoren, um Autovacuum so einzustellen, dass es mit einer bestimmten Anzahl von Tabellen und einer bestimmten Arbeitslast Schritt hält. Vorschläge Bewährte Methoden für die Arbeit mit PostgreSQL-Autovacuum. Verwenden Sie das .

Amazon RDS verwendet während der Ausführung von pg_upgrade die Option „--link“, um zu vermeiden, dass Kopien von Datendateien erstellt werden müssen. Die Schema-Metadaten müssen dennoch in der neuen Version der Datenbank wiederhergestellt werden. Selbst bei parallelem pg_restore erhöht dies die Ausfallzeit, wenn es eine beträchtliche Anzahl von Beziehungen gibt.

Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Jede Tabelle und die zugehörigen Spalten werden zu pg_depend Tabellen hinzugefügtpg_attribute, pg_class die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.

Empfohlene Maßnahme: Überprüfen Sie regelmäßig, ob Table Bloat für diese speziellen Tabellen verfügbar ist, und führen Sie gelegentlich eine VACUUM FULL Überprüfung dieser spezifischen Tabellen durch. Beachten Sie, dass VACUUM FULL für Katalogtabellen eine ACCESS EXCLUSIVE Sperre erforderlich ist, was bedeutet, dass keine anderen Abfragen auf sie zugreifen können, bis der Vorgang abgeschlossen ist.

Temporäre Tabellen werden nicht automatisch gelöscht, sondern speichern Transaktionen IDs , solange sie existieren. Wenn sie nicht entfernt werden, kann es zu einem Wraparound kommen.

Empfohlene Maßnahme: Temporäre Tabellen bleiben für die Dauer der Sitzung bestehen, in der sie erstellt wurden, oder können manuell gelöscht werden. Eine bewährte Methode zur Vermeidung lang andauernder Transaktionen mit temporären Tabellen verhindert, dass diese Tabellen zum Anstieg der maximal genutzten Transaktions-IDs beitragen.

Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Wenn Sitzungen kontinuierlich temporäre Tabellen erstellen und löschen, werden pg_depend Tabellen hinzugefügtpg_attribute, pg_class die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.

Empfohlene Maßnahme:

Nicht protokollierte Tabellen sind im Allgemeinen nicht in der logischen Replikation enthalten, einschließlich , da die logische Replikation zur Erfassung und Übertragung von Änderungen auf der WAL basiert. Lesen Sie mehr darüber, wie Sie Aurora PostgreSQL für die Replikation nicht protokollierter Tabellen konfigurieren.

Sie können nur vom Writer-Knoten im Aurora-DB-Cluster aus auf nicht protokollierte Tabellen zugreifen. Vollständige Informationen finden Sie unter Arbeiten mit nicht protokollierten Tabellen in Aurora PostgreSQL.

Manchmal nimmt der Zeitaufwand für die Planung zu und die Erläuterung der Pläne für Ihre Abfragen wird komplizierter, sodass es schwierig wird, Optimierungsmöglichkeiten zu identifizieren. Bei PostgreSQL-Versionen vor 18 können viele Partitionen mit hoher Arbeitslast zu LWLock:LockManager Wartezeiten führen.

Empfohlene Maßnahme: Legen Sie eine Mindestanzahl von Partitionen fest, die es Ihnen ermöglicht, sowohl die Organisation Ihrer Daten abzuschließen als auch gleichzeitig eine performante Abfrageausführung zu gewährleisten.

Eine sehr hohe Anzahl von Partitionen führt zu Wartungsschwierigkeiten wie der Erstellung und Entfernung vor der Erstellung und Entfernung. Autovacuum behandelt Partitionen wie normale Relationen und muss regelmäßige Säuberungen durchführen, weshalb genügend Mitarbeiter erforderlich sind, um die Aufgabe zu erledigen.

Empfohlene Maßnahme:

Temporäre Dateien sind ein notwendiger Bestandteil von PostgreSQL, wenn Abfrageergebnisse nicht in work_mem passen. Im Allgemeinen ist das in Ordnung. Wenn die Arbeitslast dies jedoch ausgiebig nutzt, deutet dies darauf hin, dass ständig große Abfragen ausgeführt werden, und Sie werden einen Rückgang feststellen FreeLocalStorage. Weitere Informationen finden Sie unter Temporäre Dateien verwalten.

Wenn Sie für jede Art von Konfigurationsänderung oder Upgrade verwenden möchten, ist es wichtig, die Auswirkungen einer hohen Anzahl von Sequenzen auf den Switchover zu verstehen. In einer der letzten Phasen eines Switchovers wird der aktuelle Wert der Sequenzen synchronisiert, und wenn es mehrere Tausend gibt, verlängert sich dadurch die Gesamtswitchover-Zeit.

Empfohlene Maßnahme: Wenn Ihre Datenbank-Arbeitslast die Verwendung einer gemeinsamen UUID anstelle eines sequence-per-table Ansatzes zulassen würde, würde dies den Synchronisationsschritt während eines Switchovers reduzieren.

Große Objekte werden derzeit während der logischen Replikation nicht in PostgreSQL repliziert. Weitere Informationen finden Sie auf der Seite Einschränkungen in der PostgreSQL-Dokumentation. In einer bedeutet dies, dass große Objekte in der blauen Umgebung nicht in die grüne Umgebung repliziert werden.

Bei einem Upgrade kann der Arbeitsspeicher knapp werden und es kann fehlschlagen, wenn Millionen großer Objekte vorhanden sind und die Instanz diese während eines Upgrades nicht verarbeiten kann. Der Upgrade-Prozess für die PostgreSQL-Hauptversion besteht aus zwei großen Phasen: dem Dumping des Schemas über pg_dump und dem Wiederherstellen über pg_restore. Wenn Ihre Datenbank Millionen großer Objekte enthält, müssen Sie sicherstellen, dass Ihre Instanz über ausreichend Speicher verfügt, um pg_dump und pg_restore während eines Upgrades zu verarbeiten, und sie auf einen größeren Instanztyp skalieren.