Compartilhar via

Limites no Banco de Dados do Azure para PostgreSQL – Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Flexível

As seções a seguir descrevem a capacidade e os limites funcionais no servidor flexível do Banco de Dados do Azure para PostgreSQL. Se quiser saber mais sobre as camadas de recursos (computação, memória, armazenamento), veja os artigos computação e armazenamento.

Número máximo de conexões

A tabela a seguir mostra o número máximo padrão de conexões para cada tipo de preço e configuração do vCore. O servidor flexível do Banco de Dados do Azure para PostgreSQL reserva 15 conexões para replicação física e monitoramento da instância do servidor flexível do Banco de Dados do Azure para PostgreSQL. Consequentemente, o valor para o máximo de conexões de usuário listadas na tabela é reduzido em 15 do total de conexões máximas.

Nome do produto vCores Tamanho da memória Número máximo de conexões Número máximo de conexões de usuário
Com capacidade de intermitência
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1.718 1.703
B8ms 8 32 GiB 3\.437 3.422
B12ms 12 48 GiB 5\.000 4.985
B16ms 16 64 GiB 5\.000 4.985
B20ms 20 80 GiB 5\.000 4.985
Uso Geral
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 GiB 859 844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 4 16 GiB 1.718 1.703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32 GiB 3\.437 3.422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64 GiB 5\.000 4.985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 GiB 5\.000 4.985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 48 192 GiB 5\.000 4.985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 64 256 GiB 5\.000 4.985
D96ds_v5 / D96ads_v5 96 384 GiB 5\.000 4.985
Otimizado para memória
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 GiB 1.718 1.703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32 GiB 3\.437 3.422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64 GiB 5\.000 4.985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 GiB 5\.000 4.985
E20ds_v4 / E20ds_v5 / E20ads_v5 20 160 GiB 5\.000 4.985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 GiB 5\.000 4.985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 GiB 5\.000 4.985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 64 432 GiB 5\.000 4.985
E96ds_v5 / E96ads_v5 96 672 GiB 5\.000 4.985

Os slots de conexão reservados, atualmente 15, podem ser alterados. Aconselhamos verificar regularmente o total de conexões reservadas no servidor. Você calcula esse número somando os valores dos parâmetros do servidor reserved_connections e superuser_reserved_connections. O número máximo de conexões de usuário disponíveis é max_connections - (reserved_connections + superuser_reserved_connections).

O valor padrão para o parâmetro do servidor max_connections é calculado quando você provisiona a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL, com base no nome do produto selecionado para sua computação. As alterações posteriores na seleção do produto para o cálculo que suporta o servidor flexível não terão efeito no valor padrão do parâmetro do servidor max_connections dessa instância. Recomendamos que sempre que alterar o produto atribuído a uma instância, você também ajuste o valor do parâmetro max_connections de acordo com os valores da tabela anterior.

Alteração do valor de max_connections

Quando você configura pela primeira vez sua instância do servidor flexível do Banco de Dados do Azure para Postgres, ela decide automaticamente o maior número de conexões que pode manipular simultaneamente. Esse número é baseado na configuração do servidor e não pode ser alterado.

No entanto, você pode usar a configuração max_connections para ajustar quantas conexões são permitidas em um determinado horário. Depois de alterar essa configuração, você precisará reiniciar o servidor para que o novo limite comece a funcionar.

Cuidado

Embora seja possível aumentar o valor max_connections além da configuração padrão, não recomendamos fazê-lo.

As instâncias podem encontrar dificuldades quando a carga de trabalho se expande e exige mais memória. À medida que o número de conexões aumenta, o uso da memória também aumenta. As instâncias com memória limitada podem enfrentar problemas como falhas ou alta latência. Embora um valor mais alto para max_connections possa ser aceitável quando a maioria das conexões estiver ociosa, ele poderá levar a problemas significativos de desempenho depois que elas se tornarem ativas.

Se você precisar de mais conexões, sugerimos que você use o PgBouncer, a solução interna do Azure para gerenciamento de pool de conexões. Use-o no modo de transação. Para começar, recomendamos que você use valores conservadores multiplicando os vCores dentro do intervalo de 2 a 5. Depois disso, monitore cuidadosamente a utilização dos recursos e o desempenho do aplicativo para garantir uma operação tranquila. Para obter informações detalhadas sobre PgBouncer, confira PgBouncer no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

Quando as conexões excedem o limite, você poderá receber o seguinte erro:

FATAL: sorry, too many clients already.

Quando você usa o servidor flexível do Banco de Dados do Azure para PostgreSQL para um banco de dados ocupado com um grande número de conexões simultâneas, pode haver uma tensão significativa nos recursos. Essa tensão pode resultar em alta utilização da CPU, especialmente quando muitas conexões são estabelecidas simultaneamente e quando as conexões têm durações curtas (menos de 60 segundos). Esses fatores podem afetar negativamente o desempenho geral do banco de dados, aumentando o tempo gasto no processamento de conexões e desconexões.

Esteja ciente de que cada conexão no servidor flexível do Banco de Dados do Azure para PostgreSQL, independentemente de estar ociosa ou ativa, consome uma quantidade significativa de recursos do seu banco de dados. Esse consumo pode levar a problemas de desempenho além da alta utilização da CPU, como contenção de disco e bloqueio. O artigo Número de conexões de banco de dados no Wiki do PostgreSQL discute esse tópico com mais detalhes. Para saber mais, confira Identificar e resolver o desempenho da conexão no servidor flexível do Banco de Dados do Azure para PostgreSQL.

Limitações funcionais

As seções a seguir listam considerações sobre o que tem e o que não tem suporte no servidor flexível do Banco de Dados do Azure para PostgreSQL.

Operações de dimensionamento

  • Neste momento, a colocação em escala do armazenamento requer a reinicialização do servidor.
  • O armazenamento do servidor só pode ser dimensionado em incrementos de 2x, veja Armazenamento para obter detalhes.
  • Atualmente, não há suporte para diminuir o tamanho de armazenamento do servidor. A única maneira de fazer isso é despejá-lo e restaurá-lo em uma nova instância de servidor flexível do Banco de Dados do Azure para PostgreSQL.

Armazenamento

  • Depois de configurar o tamanho do armazenamento, você não poderá reduzi-lo. Você precisa criar um novo servidor com o tamanho de armazenamento desejado, executar uma operação manual de despejo e restauração e migrar seus bancos de dados para o novo servidor.
  • Quando o uso do armazenamento atingir 95% ou se a capacidade disponível for inferior a 5 GiB (o que for maior), o servidor será automaticamente alternado para o modo somente leitura para evitar erros associados a situações de disco cheio. Em casos raros, se a taxa de crescimento dos dados ultrapassar o tempo necessário para mudar para o modo somente leitura, seu servidor ainda poderá ficar sem armazenamento. Você pode habilitar o crescimento automático do armazenamento para evitar esses problemas e dimensionar automaticamente seu armazenamento com base nas demandas de carga de trabalho.
  • É recomendável definir regras de alerta para storage used ou storage percent quando determinados limites forem excedidos para que você possa executar ações proativamente, como aumentar o tamanho do armazenamento. Por exemplo, você pode definir um alerta se o percentual de armazenamento exceder 80% de uso.
  • Se estiver usando replicação lógica, você deverá descartar o slot de replicação lógica no servidor primário se o assinante correspondente não existir mais. Caso contrário, os arquivos log write-ahead (WAL) se acumulam no primário e preenchem o armazenamento. Se o armazenamento exceder um determinado limite e se o slot de replicação lógica não estiver em uso (devido a um assinante indisponível), o servidor flexível do Banco de Dados do Azure para PostgreSQL descartará automaticamente esse slot de replicação lógica não utilizado. Essa ação libera arquivos WAL acumulados e impede que o servidor fique indisponível porque o armazenamento está preenchido.
  • Não damos suporte à criação de espaços de tabela. Se você estiver criando um banco de dados, não forneça um nome de espaço de tabela. O servidor flexível do Banco de Dados do Azure para PostgreSQL usa o padrão herdado do banco de dados do modelo. Não é seguro fornecer um espaço de tabela como o temporário, porque não podemos garantir que tais objetos permanecerão persistentes após eventos como reinicializações de servidores e failovers de alta disponibilidade (HA).

Rede

  • Atualmente, não há suporte para entrar e sair de uma rede virtual.
  • Atualmente, não há suporte para combinar o acesso público com a implantação em uma rede virtual.
  • Não há suporte para regras de firewall em redes virtuais. Você pode usar grupos de segurança de rede.
  • Os servidores de banco de dados de acesso público podem se conectar à Internet pública; por exemplo, através de postgres_fdw. Você não pode restringir esse acesso. Os servidores em redes virtuais podem ter acesso de saída restrito através de grupos de segurança de rede.

Alta disponibilidade

Zonas de disponibilidade

  • Não há suporte para mover servidores manualmente para uma zona de disponibilidade diferente no momento. No entanto, usando a zona de disponibilidade preferencial como zona de espera, você pode ativar a HA. Depois de estabelecer a zona de espera, você poderá fazer failover nela e, em seguida, desativar a HA.

Mecanismo Postgres, extensões e PgBouncer

  • Não há suporte para o Postgres 10 e versões anteriores porque a comunidade de código aberto as desativou. Se precisar usar uma destas versões, terá de usar a opção de servidor único do Banco de Dados do Azure para PostgreSQL, que tem suporte as versões principais mais antigas 9.5, 9.6 e 10.
  • O servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a todas as extensões contrib e muito mais. Para saber mais, confira Extensões do PostgreSQL.
  • O pooler de conexões PgBouncer interno não está disponível atualmente para servidores com capacidade de intermitência.

Operações de parada/início

  • Depois de parar a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL, ela será reiniciada automaticamente após 7 dias.

Manutenção agendada

  • Você pode alterar a janela de manutenção personalizada para qualquer dia/hora da semana. No entanto, quaisquer alterações feitas após receber a notificação de manutenção não terão impacto na próxima manutenção. As alterações entrarão em vigor somente com a manutenção agendada mensal seguinte.

Backups do servidor

  • O sistema gerencia os backups. No momento, não há como executar backups manualmente. Em vez disso, é recomendável o uso de pg_dump.

  • O primeiro instantâneo é um backup completo e os instantâneos consecutivos são backups diferenciais. Os backups diferenciais fazem backup apenas dos dados alterados desde o último backup do instantâneo.

    Por exemplo, se o tamanho do banco de dados for de 40 GB e o armazenamento provisionado for de 64 GB, o primeiro backup de instantâneo será de 40 GB. Agora, se você alterar 4 GB de dados, o próximo tamanho de backup do instantâneo diferencial será de apenas 4 GB. Os logs de transações (logs write-ahead) são separados dos backups completos e diferenciais e são arquivados continuamente.

Restauração do servidor

  • Quando você usa o recurso de restauração pontual (PITR), o novo servidor é criado com as mesmas configurações de computação e armazenamento do servidor em que se baseia.
  • Os servidores de banco de dados em redes virtuais são restaurados nas mesmas redes virtuais quando você restaura a partir de um backup.
  • O novo servidor criado durante uma restauração não possui as regras de firewall existentes no servidor original. Você precisa criar regras de firewall separadamente para o novo servidor.
  • Não há suporte para restauração para uma assinatura diferente. Como alternativa, você pode restaurar o servidor na mesma assinatura e depois migrar o servidor restaurado para uma assinatura diferente.

Segurança

  • O hash MD5 está desabilitado no Postgres 14 e versões posteriores e as senhas nativas do Postgres serão criptografadas usando apenas o método SCRAM-SHA-256.

Conteúdo relacionado