Trabalhar com arquivos de registro WAL do banco de dados PostgreSQL
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Datastream usa o registro de transações WAL (registro de gravação antecipada) do PostgreSQL para
ler streams do PostgreSQL. O registro é armazenado em arquivos WAL no servidor de banco de dados.
Cada registro no registro WAL representa uma única alteração nos dados reais em uma
das tabelas do banco de dados.
Definir parâmetros de configuração para arquivos WAL do PostgreSQL
Recomendamos que você aplique as seguintes configurações ao seu banco de dados PostgreSQL:
max_slot_wal_keep_size: defina esse parâmetro (disponível apenas para o PostgreSQL
13 e versões mais recentes) para limitar a quantidade de armazenamento usada pelo slot de replicação.
Isso é particularmente importante para transações de longa duração, que, em
casos extremos, podem fazer com que o tamanho do arquivo WAL ocupe todo o armazenamento
e cause falhas no banco de dados.
statement_timeout: defina esse parâmetro como um valor selecionado para reduzir
a latência causada por transações de longa duração. Também é possível usar
statement_timeout como uma medida de precaução alternativa para bancos de dados que
não oferecem suporte a max_slot_wal_keep_size.
wal_sender_timeout: defina esse parâmetro como 0 (para desativar o
tempo limite) ou como um valor maior ou igual a 10 minutos.
Se você planeja criar mais de 10 streams ou se o número de slots de replicação lógica usados por outros recursos, além do número de streams planejados, exceder 10, modifique os seguintes parâmetros:
max_replication_slots: aumenta o valor desse parâmetro, dependendo do número de slots de replicação definidos para o banco de dados. Você precisa de um slot de replicação por fluxo. Só é possível definir max_replication_slots
na inicialização do servidor.
max_wal_senders: aumente o valor desse parâmetro para que ele seja
maior que o valor do parâmetro max_replication_slots.
Só é possível definir max_wal_senders ao iniciar o servidor.
Otimizar arquivos de registro WAL
Para evitar alta latência dos seus streams e crescimento rápido no tamanho dos arquivos de registro WAL
ao replicar dados de uma origem do PostgreSQL, aplique as
seguintes precauções:
Evite operações grandes de longa duração, porque elas podem aumentar significativamente
o tamanho do arquivo WAL.
Use tabelas UNLOGGED ou TEMPORARY durante operações em lote.
Verifique a configuração do WAL e considere reduzir a frequência do ponto de verificação.
Para mais informações, consulte
Configuração de WAL.
Verifique se há operações DELETE grandes e considere substituí-las por operações TRUNCATE. Isso pode reduzir significativamente os dados do arquivo WAL.
No entanto, é preciso ter cuidado, porque o Datastream não replica
operações TRUNCATE.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-12 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)."]]