Mit WAL-Logdateien der PostgreSQL-Datenbank arbeiten
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Datastream verwendet das PostgreSQL-Transaktionsprotokoll WAL (Write Ahead Log), um PostgreSQL-Streams zu lesen. Das Protokoll wird in WAL-Dateien auf dem Datenbankserver gespeichert.
Jeder Datensatz im WAL-Log steht für eine einzelne Änderung an den tatsächlichen Daten in einer der Tabellen in der Datenbank.
Konfigurationsparameter für WAL-Dateien von PostgreSQL festlegen
Wir empfehlen, die folgenden Konfigurationseinstellungen auf Ihre PostgreSQL-Datenbank anzuwenden:
max_slot_wal_keep_size: Mit diesem Parameter (nur für PostgreSQL 13 und höher verfügbar) können Sie die vom Replikationsslot verwendete Speichermenge begrenzen.
Dies ist besonders wichtig für langlaufende Transaktionen, die in Extremfällen dazu führen können, dass die WAL-Datei den gesamten Speicherplatz belegt und die Datenbank abstürzt.
statement_timeout: Legen Sie für diesen Parameter einen ausgewählten Wert fest, um die Latenz zu reduzieren, die durch lang laufende Transaktionen verursacht wird. Sie können statement_timeout auch als alternative Vorsichtsmaßnahme für Datenbanken verwenden, die max_slot_wal_keep_size nicht unterstützen.
wal_sender_timeout: Legen Sie für diesen Parameter den Wert 0 fest, um die Zeitüberschreitung zu deaktivieren, oder einen Wert, der mindestens 10 Minuten beträgt.
Wenn Sie mehr als 10 Streams erstellen möchten oder die Anzahl der logischen Replikationsslots, die zusätzlich zu den geplanten Streams von anderen Ressourcen verwendet werden, 10 übersteigt, müssen Sie die folgenden Parameter ändern:
max_replication_slots: Erhöhen Sie den Wert dieses Parameters entsprechend der Anzahl der Replikationsslots, die für Ihre Datenbank festgelegt sind. Sie benötigen einen Replikationsslot pro Stream. Sie können max_replication_slots nur beim Starten des Servers festlegen.
max_wal_senders: Erhöhen Sie den Wert dieses Parameters, sodass er über dem Wert des Parameters max_replication_slots liegt.
Sie können max_wal_senders nur beim Starten des Servers festlegen.
WAL-Protokolldateien optimieren
Um eine hohe Latenz Ihrer Streams und ein schnelles Wachstum der WAL-Protokolldateien beim Replizieren von Daten aus einer PostgreSQL-Quelle zu vermeiden, sollten Sie die folgenden Vorsichtsmaßnahmen beachten:
Vermeiden Sie große, langwierige Vorgänge, da sie die Größe der WAL-Datei erheblich erhöhen können.
Verwenden Sie UNLOGGED- oder TEMPORARY-Tabellen bei Batchvorgängen.
Prüfen Sie die WAL-Konfiguration und reduzieren Sie gegebenenfalls die Häufigkeit der Checkpoints.
Weitere Informationen finden Sie unter WAL-Konfiguration.
Prüfen Sie, ob es große DELETE-Vorgänge gibt, und ersetzen Sie sie gegebenenfalls durch TRUNCATE-Vorgänge. Dadurch können die WAL-Daten erheblich reduziert werden. Sie müssen jedoch vorsichtig sein, da TRUNCATE-Vorgänge in Datastream nicht repliziert werden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eDatastream utilizes the PostgreSQL WAL transaction log, stored in WAL files, to capture changes made to the database tables.\u003c/p\u003e\n"],["\u003cp\u003eSetting the \u003ccode\u003emax_slot_wal_keep_size\u003c/code\u003e parameter is recommended to prevent the WAL file from consuming excessive storage, especially during long-running transactions, though it is not supported by certain databases like Cloud SQL and AlloyDB.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003estatement_timeout\u003c/code\u003e parameter can be configured to mitigate latency from prolonged transactions, serving as an alternative control for databases not supporting \u003ccode\u003emax_slot_wal_keep_size\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eIf you need more than 10 streams, you must adjust the \u003ccode\u003emax_replication_slots\u003c/code\u003e and \u003ccode\u003emax_wal_senders\u003c/code\u003e parameters based on the number of streams or replication slots you are using in your database.\u003c/p\u003e\n"],["\u003cp\u003eSetting \u003ccode\u003ewal_sender_timeout\u003c/code\u003e to \u003ccode\u003e0\u003c/code\u003e or a value of 10 minutes or greater is advised for better performance.\u003c/p\u003e\n"]]],[],null,["# Work with PostgreSQL database WAL log files\n\nDatastream uses the PostgreSQL WAL (Write Ahead Log) transaction log to\nread PostgreSQL streams. The log is stored in WAL files on the database server.\nEach record in the WAL log represents a single change to the actual data in one\nof the tables in the database.\n\nSet configuration parameters for PostgreSQL WAL files\n-----------------------------------------------------\n\nIt is recommended that you apply the following configuration settings to your\nPostgreSQL database:\n\n- `max_slot_wal_keep_size`: set this parameter (available only for PostgreSQL\n 13 and above) to limit the amount of storage used by the replication slot.\n This is particularly important for long-running transactions, which, in\n extreme cases, can lead to the WAL file size taking up the entire storage\n and crashing the database.\n\n | **Note:** Some managed databases, such as Cloud SQL and AlloyDB for PostgreSQL, don't support `max_slot_wal_keep_size`.\n- `statement_timeout`: set this parameter to a selected value to reduce\n latency caused by long-running transactions. You can also use\n `statement_timeout` as an alternative precaution measure for databases that\n don't support `max_slot_wal_keep_size`.\n\n- `wal_sender_timeout`: set this parameter to `0` (to disable the\n timeout) or to a value greater than or equal to 10 minutes.\n\nIf you plan to create more than 10 streams, or the number of logical replication\nslots that is used by other resources in addition to the number of planned\nstreams exceeds 10, make sure to modify the following parameters:\n\n- `max_replication_slots`: increase the value of this parameter, depending on\n the number of replication slots set for your database (you need 1\n replication slot per stream). You can only set `max_replication_slots`\n at server start.\n\n- `max_wal_senders`: increase the value of this parameter, so that it's\n greater than the value of the `max_replication_slots` parameter.\n You can only set `max_wal_senders` when you start the server.\n\nOptimize WAL log files\n----------------------\n\nTo avoid high latency of your streams and rapid growth in the size of WAL log\nfiles when replicating data from a PostgreSQL source, consider applying the\nfollowing precautions:\n\n- Avoid large long-running operations because they can significantly increase the size of your WAL file.\n- Use `UNLOGGED` or `TEMPORARY` tables during batch operations.\n- Check your WAL configuration and consider reducing the checkpoint frequency. For more information, see [WAL configuration](https://www.postgresql.org/docs/current/wal-configuration.html)\n- Check for large `DELETE` operations and consider replacing them with `TRUNCATE` operations. Doing this can significantly reduce WAL file data, however you need to be cautious, because Datastream doesn't replicate `TRUNCATE` operations.\n\nWhat's next\n-----------\n\n- Learn more about [PostgreSQL as a\n source](/datastream/docs/sources-postgresql).\n- Learn more about [configuring a source PostgreSQL\n database](/datastream/docs/configure-your-source-postgresql-database)."]]
