Beschreiben der Write-Ahead-Protokollierung

  • 3 Minuten

Wenn Änderungen in der Datenbank vorgenommen werden, z. B. durch INSERT oder DELETE, werden diese Änderungen zunächst in ein Protokoll und erst dann in Datendateien auf einem Datenträger geschrieben. Dieser Vorgang wird als Write-Ahead-Protokollierung bezeichnet, da Änderungen in das Protokoll geschrieben werden, bevor dafür ein Commit für die Datendateien erfolgt. Bei einem Problem, z. B. Stromausfall, enthält das Protokoll stets die neuesten Daten und kann verwendet werden, um den konsistenten Zustand der Datenbank sicherzustellen.

Ein zweiter Vorteil ist, dass, wenn Änderungen zuerst in das Protokoll geschrieben werden, Änderungen an Tabellen und Indizes in Batches statt einzeln geschrieben werden können. Durch diesen Prozess verringert sich die Anzahl der Schreibvorgänge auf den Datenträger, die erforderlich sind, um Tabellen und Indizes auf dem neuesten Stand zu halten. Schreibvorgänge in das Protokoll sind schnell, da sie sequenziell erfolgen. Langsamere Schreibvorgänge in Tabellen und Indizes können sicher in Batches erfolgen, da alle Daten aus dem Protokoll wiederhergestellt werden können. Für Workloads, die in der Regel viele kleine Aktualisierungen umfassen, wird die Leistung verbessert.

Hinweis

Bei lokalen Implementierungen von PostgreSQL wird die Protokolldatei im Verzeichnis pg_wal gespeichert. Azure Database for PostgreSQL bietet keinen Zugriff auf das Dateisystem, sodass Sie sich nicht um die physische Speicherung der Protokolldatei kümmern müssen.

Es gibt mehrere Serverparameter, mit denen Sie die Funktionsweise der Write-Ahead-Protokollierung steuern und sie für Ihre Workloads optimieren können:

  • commit_delay: die Verzögerung zwischen dem Committen einer Transaktion und Leeren des Protokolls auf den Datenträger.
  • wal_buffers: die Anzahl der Seitenpuffer auf dem Datenträger im gemeinsam genutzten Speicher für die Write-Ahead-Protokollierung (WAL).
  • max_wal_size: die maximale Größe für das Wachstum der WAL, bevor ein automatischer Prüfpunkt ausgelöst wird.
  • wal_writer_delay: Zeitintervall zwischen WAL-Leerungen, die vom WAL-Writer ausgeführt werden.
  • wal_compression: gibt an, ob Schreibvorgänge für ganze Seiten in der WAL-Datei komprimiert werden.
  • wal_level: bestimmt, wie viele Informationen in das WAL geschrieben werden. Die zulässigen Werte sind REPLICA oder LOGICAL.

Point-in-Time-Wiederherstellung

Der Hauptzweck des Write-Ahead-Protokolls (WAL) besteht darin, Konsistenz und Beständigkeit der Datenbank im Falle eines Absturzes zu gewährleisten. Die lokale Version von PostgreSQL ermöglicht die Verwendung des Protokolls als Archiv, sodass Sie es mithilfe der Konfigurationseinstellungen archive_mode und archive_command zeitpunktbezogen wiederherstellen können.

Azure Database for PostgreSQL ist ein verwalteter Dienst, der keinen Zugriff auf das zugrunde liegende Dateisystem erlaubt. Der Dienst bietet jedoch automatische vollständige Sicherungen des Servers einschließlich aller Datenbanken. Durch diese Sicherung können Sie Ihre Daten zeitpunktbezogen neu erstellen. Sicherungen werden automatisch geplant und erfolgen einmal täglich. Wenn eine Wiederherstellung erforderlich ist, kann diese bis zu der Anzahl von Tagen erfolgen, die Sie für die Aufbewahrung von Sicherungen angegeben haben, höchstens jedoch bis zu 35 Tage. So geben Sie an, wie lange Sicherungen aufbewahrt werden sollen:

  1. Navigieren Sie im Azure-Portal zu Ihrer Instanz von Azure Database for PostgreSQL – Flexibler Server.
  2. Wählen Sie im Abschnitt Übersicht Ihre Konfiguration aus.
  3. Suchen Sie unter „Sicherungen“ nach Aufbewahrungsdauer für Sicherungen (in Tagen). Mit dem Schieberegler können Sie die Anzahl der Tage auswählen, die Sicherungen aufbewahrt werden sollen.
  4. Wählen Sie Speichern aus, um Ihre Änderungen zu übernehmen.