Compartilhar via

Limites no Banco de Dados do Azure para PostgreSQL

As seções a seguir descrevem a capacidade e os limites funcionais para instâncias de 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 padrão máximo de conexões para cada tipo de preço e configuração do vCore. Uma instância de 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 de servidor flexível do Banco de Dados do Azure para PostgreSQL. Consequentemente, a tabela reduz o valor para o máximo de conexões de usuário 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 oito 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 oito 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 oito 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 em 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 sistema calcula o valor padrão para o parâmetro de servidor max_connections ao provisionar a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL, com base no nome do produto que você seleciona para sua computação. As alterações subsequentes da seleção do produto na computação que dá suporte à instância não terão nenhum efeito sobre o valor padrão para o max_connections parâmetro de servidor 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. A configuração do servidor determina esse número e você não pode alterá-lo.

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.

Atenção

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, consulte PgBouncer no Banco de Dados do Azure para PostgreSQL.

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

FATAL: sorry, too many clients already.

Quando você estiver usando uma instância de 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.

Cada conexão em uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, independentemente de ser ociosa ou ativa, consome uma quantidade significativa de recursos do 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 este artigo com mais detalhes. Para saber mais, consulte Identificar e resolver o desempenho da conexão no Azure Postgres.

Limitações funcionais

As seções a seguir listam considerações sobre o que é e não é suportado para suas instâncias de servidor flexível do Azure Database 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. Consulte Armazenamento para obter detalhes.
  • Atualmente, não há suporte para a diminuição do tamanho do armazenamento do servidor. A única maneira de fazer essa operação é despejar e restaurá-la 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 atinge 95% ou se a capacidade disponível for menor que 5 GiB (o que for mais), o sistema alterna automaticamente o servidor 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), uma instância de 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. Uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usa o espaço de tabela padrão herdado pelo banco de dados de 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).
  • Arquivos de dados órfãos e discrepâncias de uso de disco: em casos raros, o PostgreSQL pode deixar para trás arquivos de dados órfãos em disco — arquivos que não têm mais entradas correspondentes no catálogo do sistema do banco de dados (que rastreia todas as tabelas e dados). Isso pode acontecer se uma tabela for criada e preenchida dentro de uma transação que não for concluída com êxito (por exemplo, devido a uma falha ou interrupção do servidor), resultando em uma incompatibilidade entre o tamanho relatado pelo banco de dados e o uso real do disco. Esse comportamento é da base de código da comunidade PostgreSQL e não é específico do Azure. A comunidade postgreSQL está ciente do problema e está explorando aprimoramentos para limpeza automática em versões futuras. Para obter mais detalhes, consulte: PostgreSQL: Arquivos Órfãos no PostgreSQL. Isso pode levar a um consumo de armazenamento ou disco inesperadamente alto.
    • Como detectar: compare o tamanho relatado pelo banco de dados (usando consultas como SELECT pg_database_size('your_database')) com as métricas do portal do Azure para uso real do disco. Se houver uma discrepância significativa, arquivos órfãos podem ser a causa. Em caso afirmativo:
      • Execute VACUUM FULL nas tabelas afetadas para recuperar espaço (observação: isso é de uso intensivo de recursos, requer um bloqueio de tabela e pode exigir tempo de inatividade).
      • Como alternativa, use ferramentas como extensões de pg_repack ou pg_squeeze para reorganização sem tempo de inatividade, mas teste primeiro em um ambiente de não produção.
      • Monitore por meio das métricas do portal do Azure para limites de uso de disco. Se o problema persistir ou você não tiver certeza, entre em contato com o Suporte do Azure para obter assistência.
    • Como evitar: verifique se as transações são gerenciadas corretamente em seus aplicativos para minimizar operações incompletas. Monitore regularmente o uso de disco por meio das métricas do portal do Azure. A atualização para a versão mais recente do PostgreSQL com suporte pode incluir correções da comunidade para problemas relacionados.

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.
  • As redes virtuais não dão suporte a regras de firewall. 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

  • Atualmente, não há suporte para mover servidores manualmente para uma zona de disponibilidade diferente. 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

  • Uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a todos os recursos do mecanismo PostgreSQL, incluindo particionamento, replicação lógica e wrappers de dados externos.
  • Uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a todas as contrib extensões e muito mais. Para saber mais, confira Extensões do PostgreSQL.
  • Atualmente, os servidores burstable não têm acesso ao pooler de conexões interno do PgBouncer.

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á iniciada automaticamente após sete 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, você não pode 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ê está usando o recurso PITR (restauração pontual no tempo), o sistema cria o novo servidor com as mesmas configurações de computação e armazenamento que o servidor no qual ele se baseia.
  • O sistema restaura servidores de banco de dados em redes virtuais nas mesmas redes virtuais quando você restaura 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 em 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

  • As versões Postgres 14 e posteriores desabilitam o hash MD5 e o sistema faz o hash de senhas Postgres nativas usando apenas o método SCRAM-SHA-256.

Conteúdo relacionado

  • Last updated on