max_replication_slots
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o número máximo de slots de replicação definidos simultaneamente. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho máximo de WAL que pode ser reservado por slots de replicação. Os slots de replicação serão marcados como com falha e os segmentos liberados para exclusão ou reciclagem, se esse espaço for ocupado pela WAL no disco. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o número máximo de slots de replicação definidos simultaneamente. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho máximo de WAL que pode ser reservado por slots de replicação. Os slots de replicação serão marcados como com falha e os segmentos liberados para exclusão ou reciclagem, se esse espaço for ocupado pela WAL no disco. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho máximo de WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho máximo de WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho máximo de WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_slot_wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho máximo de WAL que pode ser reservado por slots de replicação. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
-1 |
| Valores permitidos |
-1 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tamanho dos arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
400 |
| Valores permitidos |
400 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o número de arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
25 |
| Valores permitidos |
25 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
|
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
2-262143 |
| Tipo de parâmetro |
estático |
| Documentation |
max_replication_slots |
Notas específicas do Azure
O valor padrão do parâmetro max_replication_slots é 10. Se você habilitar a alta disponibilidade, precisará de um mínimo de 4 max_replication_slots para que a alta disponibilidade funcione corretamente.
Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_replication_slots para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_replication_slot. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
max_wal_senders
| Attribute |
Valor |
| 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 |
número inteiro |
| Valor predefinido |
10 |
| Valores permitidos |
5-100 |
| Tipo de parâmetro |
estático |
| Documentation |
max_wal_senders |
Notas específicas do Azure
O valor padrão para o max_wal_senders conjunto de parâmetros de servidor quando você provisiona a instância do Banco de Dados do Azure para o servidor flexível PostgreSQL nunca deve ser diminuído 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 mais alto para ser capaz de lidar com a replicação lógica de um número substancial de tabelas, tenha em mente os seguintes pontos importantes:
- Logicamente, replicar um grande número de tabelas não precisa necessariamente de um grande número de remetentes WAL.
- A única razão pela qual você precisa de um emissor WAL separado para cada tabela ou grupo de tabelas é caso precise de assinaturas distintas para cada uma dessas tabelas ou grupos.
- Independentemente do número de WAL senders que são utilizados para replicação física e lógica, todos eles ficam ativos de uma só vez, sempre que qualquer back-end grava algo no write-ahead log. Quando isso acontece, os remetentes WAL atribuídos para fazer replicação lógica são todos ativados para:
- Decodificar todos os novos registros no WAL,
- Filtrar registros de log nos quais eles não estão interessados,
- Replique os dados relevantes para cada um deles.
- Os emissores WAL são semelhantes a conexões no sentido de que, se estiverem ociosos, não importa quantos sejam. 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, porque a decodificação lógica é bastante cara de CPU. Cada trabalhador tem que decodificar toda a WAL, mesmo que ela replique apenas as operações que afetam uma única tabela, e isso representa uma pequena porcentagem de todos os dados no log write-ahead. Para replicação física, não é assim tão importante, porque os processos de envio WAL não consomem CPU tão intensamente e são primeiramente limitados pela largura de banda da rede.
- Portanto, em geral, é melhor não ter muito mais remetentes WAL do que vCores.
- É uma boa prática adicionar espaço para alguns remetentes WAL extras para acomodar crescimento futuro ou picos temporários nas conexões de replicação. Os dois exemplos seguintes podem ajudar a ilustrá-lo melhor.
- Para um servidor com 8 vCores, HA desabilitado, 2 réplicas de leitura e 3 slots de replicação lógica, convém configurar
max_wal_senders como a soma de slots físicos para HA (0) + slots físicos para réplicas de leitura (2) + slots lógicos(3) + alguns extras para crescimento futuro, considerando vCores disponíveis (1) = 6.
- Para um servidor com 16 vCores, com HA ativado, 4 réplicas de leitura e 5 slots de replicação lógica, pode ser conveniente configurar
max_wal_senders como a soma dos slots físicos para HA (2) + slots físicos para réplicas de leitura (4) + slots lógicos (5), mais alguns extras para expansão futura, considerando os vCores disponíveis (2) = 13.
- Se você habilitar a alta disponibilidade, precisará de um mínimo de 4
max_wal_senders para que a alta disponibilidade funcione corretamente. Para um servidor com alta disponibilidade ativa, além de 5 réplicas de leitura e 12 slots de replicação lógica, você pode querer configurar max_wal_senders para 21. Isso ocorre porque cada réplica de leitura e cada slot de replicação lógica necessita de um max_wal_senders. Portanto, requer um total de 1 (slot) * 5 (réplicas de leitura) + 12 (slots de replicação lógica) + 4 (para alta disponibilidade funcionar corretamente) = 21.
- Se você ainda considerar que o valor máximo permitido para este 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 que você precisaria para que seu cenário tivesse um desempenho adequado.
track_commit_timestamp
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Coleta o tempo de confirmação da transação. |
| Tipo de dados |
Booleano |
| Valor predefinido |
off |
| Valores permitidos |
on,off |
| Tipo de parâmetro |
estático |
| Documentation |
track_commit_timestamp |
wal_keep_segments
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o número de arquivos WAL mantidos para servidores em espera. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
25 |
| Valores permitidos |
25 |
| Tipo de parâmetro |
só de leitura |
| Documentation |
|
wal_sender_timeout
| Attribute |
Valor |
| Categoria |
Servidores de replicação/envio |
| Description |
Define o tempo máximo de espera pela replicação WAL. |
| Tipo de dados |
número inteiro |
| Valor predefinido |
60000 |
| Valores permitidos |
0-2147483647 |
| Tipo de parâmetro |
dynamic |
| Documentation |
wal_sender_timeout |