Utilizzo dei file di log WAL del database PostgreSQL
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Datastream utilizza il log delle transazioni WAL (Write Ahead Log) di PostgreSQL per leggere gli stream PostgreSQL. Il log viene archiviato in file WAL sul server di database.
Ogni record nel log WAL rappresenta una singola modifica ai dati effettivi in una
delle tabelle del database.
Imposta i parametri di configurazione per i file WAL di PostgreSQL
Ti consigliamo di applicare le seguenti impostazioni di configurazione al database PostgreSQL:
max_slot_wal_keep_size: imposta questo parametro (disponibile solo per PostgreSQL 13 e versioni successive) per limitare la quantità di spazio di archiviazione utilizzata dallo slot di replica.
Questo è particolarmente importante per le transazioni che richiedono molto tempo, che, in casi estremi, possono portare le dimensioni del file WAL a occupare l'intero spazio di archiviazione e a causare l'arresto anomalo del database.
statement_timeout: imposta questo parametro su un valore selezionato per ridurre la latenza causata da transazioni di lunga durata. Puoi anche utilizzare
statement_timeout come misura precauzionale alternativa per i database che
non supportano max_slot_wal_keep_size.
wal_sender_timeout: imposta questo parametro su 0 (per disattivare il timeout) o su un valore maggiore o uguale a 10 minuti.
Se prevedi di creare più di 10 stream o se il numero di slot di replica logica utilizzati da altre risorse oltre al numero di stream pianificati supera 10, assicurati di modificare i seguenti parametri:
max_replication_slots: aumenta il valore di questo parametro, a seconda del numero di slot di replica impostati per il database (è necessario un slot di replica per stream). Puoi impostare max_replication_slots
solo all'avvio del server.
max_wal_senders: aumenta il valore di questo parametro in modo che sia superiore al valore del parametro max_replication_slots.
Puoi impostare max_wal_senders solo quando avvii il server.
Ottimizzare i file di log WAL
Per evitare una latenza elevata degli stream e una crescita rapida delle dimensioni dei file log WAL quando replichi i dati da un'origine PostgreSQL, ti consigliamo di applicare le seguenti precauzioni:
Evita operazioni di grandi dimensioni e di lunga durata perché possono aumentare notevolmente le dimensioni del file WAL.
Utilizza le tabelle UNLOGGED o TEMPORARY durante le operazioni collettive.
Controlla la configurazione WAL e valuta la possibilità di ridurre la frequenza dei checkpoint.
Per ulteriori informazioni, consulta la sezione Configurazione WAL.
Controlla se sono presenti operazioni DELETE di grandi dimensioni e valuta la possibilità di sostituirle con operazioni TRUNCATE. In questo modo, puoi ridurre notevolmente i dati dei file WAL, ma devi fare attenzione perché Datastream non esegue la replica delle operazioni TRUNCATE.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
