max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de slots de replicação definidos simultaneamente. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho máximo do WAL que pode ser reservado por slots de replicação. Os slots de replicação serão marcados como com falha e segmentos liberados para exclusão ou reciclagem, se esse espaço for ocupado pelo WAL no disco. |
| Tipo de dados |
inteiro |
| Valor padrão |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de slots de replicação definidos simultaneamente. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho máximo do WAL que pode ser reservado por slots de replicação. Os slots de replicação serão marcados como com falha e segmentos liberados para exclusão ou reciclagem, se esse espaço for ocupado pelo WAL no disco. |
| Tipo de dados |
inteiro |
| Valor padrão |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Especifica o número máximo de slots de replicação que o servidor pode suportar. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho máximo do WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
inteiro |
| Valor padrão |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Especifica o número máximo de slots de replicação que o servidor pode suportar. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho máximo do WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
inteiro |
| Valor padrão |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Especifica o número máximo de slots de replicação que o servidor pode suportar. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho máximo do WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
inteiro |
| Valor padrão |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Especifica o número máximo de slots de replicação que o servidor pode suportar. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho máximo do WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
inteiro |
| Valor padrão |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Especifica o número máximo de slots de replicação que o servidor pode suportar. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número de arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
25 |
| Valores permitidos |
25 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
|
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Especifica o número máximo de slots de replicação que o servidor pode suportar. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Observações específicas do Azure
O valor padrão do max_replication_slots parâmetro é 10. Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_replication_slot. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
max_wal_senders
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número máximo de processos de remetente WAL em execução simultânea. |
| Tipo de dados |
inteiro |
| Valor padrão |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Observações específicas do Azure
O valor padrão do parâmetro de max_wal_senders servidor definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Ao considerar a necessidade de aumentar max_wal_senders para um valor muito maior para poder lidar com a replicação lógica de um número substancial de tabelas, tenha os seguintes pontos importantes em mente:
- A replicação lógica de um grande número de tabelas não requer necessariamente um grande número de remetentes de WAL.
- O único motivo por que você precisa de um remetente de WAL separado por tabela ou por grupo de tabelas é se precisar de assinaturas separadas para cada uma dessas tabelas ou grupos de tabelas.
- Qualquer número de remetentes WAL que estão sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que algum backend grava algo no log de escrita antecipada. Quando isso acontece, os remetentes do WAL que são atribuídos para fazer a replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtre os registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Remetentes WAL são semelhantes a conexões em que, se estão ociosos, não importa quantos há. No entanto, se eles estiverem ativos, eles apenas competirão pelos mesmos recursos e o desempenho pode acabar sendo terrivelmente ruim. Isso é especialmente verdadeiro para remetentes com replicação lógica, pois a decodificação lógica é bastante cara para a CPU. Cada trabalhador precisa decodificar o WAL inteiro, mesmo que ele só replique as operações que afetam uma única tabela, representando assim uma pequena porcentagem de todos os dados no log de antecipação. Para replicação física, não é tão importante, pois os WAL senders não consomem CPU tão intensamente, e eles tendem a ser limitados primeiro pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muitos mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns enviadores WAL extras para acomodar o crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos a seguir podem ajudar a ilustrar melhor.
- Para um servidor com 8 vCores, com HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, você deve configurar
max_wal_senders como a soma dos slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos (3), mais alguns slots adicionais para crescimento futuro, considerando a disponibilidade de vCores (1), resultando em um total de 6.
- Para um servidor com 16 vCores, HA habilitado, 4 réplicas de leitura e 5 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos(5) + alguns adicionais para crescimento futuro, considerando vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de, no mínimo, 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade habilitada, além de 5 réplicas de leitura e 12 slots de replicação lógica, convém configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica requer um max_wal_senders. Portanto, ele requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para que a alta disponibilidade funcione corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para esse parâmetro é muito baixo para suas necessidades, entre em contato conosco, descreva seu cenário em detalhes e explique o que você considera que seria o valor mínimo aceitável necessário para que seu cenário fosse executado corretamente.
track_commit_timestamp
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
boolean |
| Valor padrão |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o número de arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
inteiro |
| Valor padrão |
25 |
| Valores permitidos |
25 |
| Tipo de parâmetro |
somente leitura |
| Documentation |
|
wal_sender_timeout
| Attribute |
Value |
| Categoria |
Servidores de Replicação/Envio |
| Description |
Define o tempo máximo de espera para replicação do WAL. |
| Tipo de dados |
inteiro |
| Valor padrão |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |