Utiliser les fichiers journaux WAL de la base de données PostgreSQL
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Datastream utilise le journal de transactions WAL (Write Ahead Log) de PostgreSQL pour lire les flux PostgreSQL. Le journal est stocké dans des fichiers WAL sur le serveur de base de données.
Chaque enregistrement du journal WAL représente une seule modification apportée aux données réelles de l'une des tables de la base de données.
Définir des paramètres de configuration pour les fichiers WAL PostgreSQL
Nous vous recommandons d'appliquer les paramètres de configuration suivants à votre base de données PostgreSQL:
max_slot_wal_keep_size: définissez ce paramètre (disponible uniquement pour PostgreSQL 13 et versions ultérieures) pour limiter la quantité de stockage utilisée par l'emplacement de réplication.
Cela est particulièrement important pour les transactions de longue durée, qui, dans des cas extrêmes, peuvent entraîner la taille du fichier WAL occupant l'ensemble de l'espace de stockage et le plantage de la base de données.
statement_timeout: définissez ce paramètre sur une valeur sélectionnée pour réduire la latence causée par les transactions de longue durée. Vous pouvez également utiliser statement_timeout comme mesure de précaution alternative pour les bases de données qui ne sont pas compatibles avec max_slot_wal_keep_size.
wal_sender_timeout: définissez ce paramètre sur 0 (pour désactiver le délai avant expiration) ou sur une valeur supérieure ou égale à 10 minutes.
Si vous prévoyez de créer plus de 10 flux, ou si le nombre d'emplacements de réplication logiques utilisés par d'autres ressources en plus du nombre de flux planifiés dépasse 10, veillez à modifier les paramètres suivants:
max_replication_slots: augmentez la valeur de ce paramètre en fonction du nombre d'emplacements de réplication définis pour votre base de données (vous avez besoin d'un emplacement de réplication par flux). Vous ne pouvez définir max_replication_slots qu'au démarrage du serveur.
max_wal_senders: augmentez la valeur de ce paramètre afin qu'elle soit supérieure à la valeur du paramètre max_replication_slots.
Vous ne pouvez définir max_wal_senders que lorsque vous démarrez le serveur.
Optimiser les fichiers journaux WAL
Pour éviter une latence élevée de vos flux et une croissance rapide de la taille des fichiers journaux WAL lors de la réplication de données à partir d'une source PostgreSQL, envisagez d'appliquer les précautions suivantes:
Évitez les opérations volumineuses et de longue durée, car elles peuvent augmenter considérablement la taille de votre fichier WAL.
Utilisez des tables UNLOGGED ou TEMPORARY lors des opérations par lots.
Vérifiez la configuration de votre journal WAL et envisagez de réduire la fréquence des points de contrôle.
Pour en savoir plus, consultez la section Configuration du journal WAL.
Recherchez les opérations DELETE volumineuses et envisagez de les remplacer par des opérations TRUNCATE. Cela peut réduire considérablement les données de fichier WAL. Toutefois, vous devez faire preuve de prudence, car Datastream ne réplique pas les opérations TRUNCATE.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
