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 serão 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 serão 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 para o parâmetro do servidor max_wal_senders definido quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL nunca deve ser reduzido abaixo de 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 que seja o número de remetentes WAL que estejam sendo utilizados para replicação física e lógica, todos eles se tornam ativos de uma só vez, sempre que qualquer back-end grava algo no log de gravação antecipada. Quando isso acontece, todos os remetentes WAL atribuídos para fazer a replicação lógica são 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.
- Os remetentes WAL são semelhantes às conexões no sentido de que, se estiverem ociosos, não importa quantos existem. 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 todo o WAL, mesmo que ele replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log de gravação antecipada. 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 remetentes 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, alta disponibilidade habilitada, 4 réplicas de leitura e 5 slots de replicação lógica, talvez você queira 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 |