Trabajar con archivos de registro WAL de la base de datos de PostgreSQL
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Datastream usa el registro de transacciones WAL (registro de escritura por adelantado) de PostgreSQL para leer transmisiones de PostgreSQL. El registro se almacena en archivos WAL en el servidor de la base de datos.
Cada registro del registro de WAL representa un solo cambio en los datos reales de una de las tablas de la base de datos.
Establece parámetros de configuración para los archivos WAL de PostgreSQL
Te recomendamos que apliques la siguiente configuración a tu base de datos
de PostgreSQL:
max_slot_wal_keep_size: Establece este parámetro (disponible solo para PostgreSQL 13 y versiones posteriores) para limitar la cantidad de almacenamiento que usa el espacio de replicación.
Esto es especialmente importante para las transacciones de larga duración, que, en
casos extremos, pueden provocar que el tamaño del archivo WAL ocupe todo el almacenamiento
y haga que la base de datos falle.
statement_timeout: Establece este parámetro en un valor seleccionado para reducir la latencia causada por las transacciones de larga duración. También puedes usar
statement_timeout como medida de precaución alternativa para bases de datos que
no admiten max_slot_wal_keep_size.
wal_sender_timeout: Establece este parámetro en 0 (para inhabilitar el tiempo de espera) o en un valor mayor o igual a 10 minutos.
Si planeas crear más de 10 transmisiones o si la cantidad de ranuras de replicación lógicas que usan otros recursos, además de la cantidad de transmisiones planificadas, supera los 10, asegúrate de modificar los siguientes parámetros:
max_replication_slots: Aumenta el valor de este parámetro, según la cantidad de ranuras de replicación configuradas para tu base de datos (necesitas 1 ranura de replicación por flujo). Solo puedes configurar max_replication_slots al iniciar el servidor.
max_wal_senders: Aumenta el valor de este parámetro para que sea mayor que el valor del parámetro max_replication_slots.
Solo puedes configurar max_wal_senders cuando inicias el servidor.
Optimiza los archivos de registro WAL
Para evitar una latencia alta de tus transmisiones y un crecimiento rápido en el tamaño de los archivos de registro de WAL cuando se replican datos de una fuente de PostgreSQL, considera aplicar las siguientes precauciones:
Evita las operaciones de larga duración, ya que pueden aumentar significativamente el tamaño del archivo WAL.
Usa tablas UNLOGGED o TEMPORARY durante las operaciones por lotes.
Verifica la configuración de WAL y considera reducir la frecuencia de los puntos de control.
Para obtener más información, consulta Configuración de WAL.
Verifica si hay operaciones DELETE grandes y considera reemplazarlas por operaciones TRUNCATE. De esta manera, se pueden reducir significativamente los datos del archivo WAL.
Sin embargo, debes tener cuidado, ya que Datastream no replica
las operaciones de TRUNCATE.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)."]]
