Partilhar 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íveis do Banco de Dados do Azure para PostgreSQL. Se quiser saber mais sobre as camadas de recursos (computação, memória, armazenamento), consulte os artigos de computação e armazenamento .

Número máximo de ligações

A tabela a seguir mostra o número máximo padrão de conexões para cada camada de preço e configuração 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 ligações Máximo de conexões de usuário
Burstable
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
Fins Gerais
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
Memória otimizada
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 em 15, podem mudar. Aconselhamos verificar regularmente o total de conexões reservadas no servidor. Você calcula reserved_connections esse número somando os valores dos parâmetros e superuser_reserved_connections do servidor. 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 max_connections parâmetro de servidor quando você provisiona a instância do Banco de Dados do Azure para servidor flexível PostgreSQL, com base no nome do produto selecionado para sua computação. Quaisquer alterações subsequentes na seleção de produtos para o servidor de computação que suporta a instância não terão qualquer efeito sobre o valor padrão para o 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 max_connections parâmetro de acordo com os valores da tabela anterior.

Alterar o valor max_connections

Quando você configura pela primeira vez seu Banco de Dados do Azure para instância de servidor flexível do Postgres, ele 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 max_connections configuração para ajustar quantas conexões são permitidas em um determinado momento. Depois de alterar essa configuração, você precisa reiniciar o servidor para que o novo limite comece a funcionar.

Atenção

Embora seja possível aumentar o valor de max_connections além da configuração padrão, desaconselhamos isso.

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 de memória também aumenta. 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 está ociosa, isso pode levar a problemas de desempenho significativos depois que elas se tornam ativas.

Se você precisar de mais conexões, sugerimos que use o PgBouncer, a solução interna do Azure para gerenciamento do 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, monitore cuidadosamente a utilização de recursos e o desempenho do aplicativo para garantir uma operação suave. 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ê pode 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 pressão significativa sobre os 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 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 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 é ou não suportado para seu Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL.

Operações de escala

  • Neste momento, a expansão do armazenamento do servidor requer uma reinicialização do servidor.
  • O armazenamento do servidor só pode ser dimensionado em incrementos de 2x. Consulte Armazenamento para obter detalhes.
  • Atualmente, não suportamos a diminuição do tamanho do armazenamento do servidor. A única maneira de fazer essa operação é despejá-la 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, não é possível 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 inferior a 5 GiB (o que for maior), 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 de dados superar o tempo necessário para mudar para o modo somente leitura, o servidor ainda poderá ficar sem armazenamento. Você pode habilitar o crescimento automático do armazenamento para evitar esses problemas e dimensionar automaticamente o armazenamento com base nas demandas de carga de trabalho.
  • Recomendamos definir regras de alerta para storage used ou storage percent quando elas excederem determinados limites, para que você possa tomar medidas proativas, como aumentar o tamanho do armazenamento. Por exemplo, você pode definir um alerta se a porcentagem de armazenamento exceder 80% de uso.
  • Se você estiver usando a replicação lógica, 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 de 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 evita que o servidor fique indisponível porque o armazenamento está cheio.
  • Não apoiamos a criação de espaços de mesa. 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 que o banco de dados de modelo herda. Não é seguro fornecer um espaço de tabela como o temporário, porque não podemos garantir que esses objetos permaneçam persistentes após eventos como reinicializações do servidor e failovers de alta disponibilidade (HA).
  • Ficheiros de Dados Órfãos e Discrepâncias no Uso do Disco: Em casos raros, o PostgreSQL pode deixar ficheiros de dados órfãos no disco — ficheiros que já não têm entradas correspondentes no catálogo do sistema da base de dados (que regista todas as tabelas e dados). Isto pode acontecer se uma tabela for criada e preenchida numa transação que não for concluída com sucesso (por exemplo, devido a uma falha ou interrupção do servidor), resultando numa incompatibilidade entre o tamanho reportado pela base de dados e o uso real do disco. Este comportamento provém da base de código da comunidade PostgreSQL e não é específico do Azure. A comunidade PostgreSQL está ciente do problema e está a explorar melhorias para a limpeza automática em futuras versões. Para mais detalhes, veja: PostgreSQL: Ficheiros Órfãos em PostgreSQL. Isto pode levar a um consumo inesperadamente elevado de disco ou armazenamento.
    • Como Detetar: Compare o tamanho reportado pela base de dados (usando consultas como SELECT pg_database_size('your_database')) com métricas do portal Azure para o uso real do disco. Se houver uma discrepância significativa, ficheiros órfãos podem ser a causa. Caso afirmativo:
      • Execute VACUUM FULL nas mesas afetadas para recuperar espaço (nota: isto consome muitos recursos, requer bloqueio de mesa e pode exigir tempo de inatividade).
      • Alternativamente, use ferramentas como pg_repack ou extensões pg_squeeze para reorganização sem tempo de inatividade, mas teste primeiro num ambiente não produtivo.
      • Monitorizar através das métricas do portal Azure para os limites de utilização do disco. Se o problema persistir ou tiver dúvidas, contacte o Suporte Azure para obter ajuda.
    • Como Prevenir: Garanta que as transações são devidamente geridas nas suas aplicações para minimizar operações incompletas. Monitoriza regularmente o uso do disco através das métricas do portal Azure. A atualização para a versão mais recente suportada do PostgreSQL pode incluir correções da comunidade para problemas relacionados.

Rede

  • Atualmente, não suportamos entrar e sair de uma rede virtual.
  • Atualmente, não suportamos a combinação de acesso público com implantação em uma rede virtual.
  • As redes virtuais não suportam regras de firewall. Em vez disso, 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. Não é possível restringir esse acesso. Os servidores em redes virtuais podem ter acesso de saída restrito através de grupos de segurança de rede.

Elevada disponibilidade

Zonas de disponibilidade

  • Atualmente, não suportamos a movimentação manual de servidores para uma zona de disponibilidade diferente. No entanto, usando a zona de disponibilidade preferida como a zona de espera, você pode ativar o HA. Depois de estabelecer a zona de espera, você pode fazer failover para ela e, em seguida, desativar o HA.

Motor Postgres, extensões e PgBouncer

  • Uma instância de servidor flexível do Banco de Dados Azure para PostgreSQL dá suporte a todos os recursos do mecanismo PostgreSQL, incluindo particionamento, replicação lógica e envoltórios 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 obter mais informações, consulte Extensões PostgreSQL.
  • Atualmente, os servidores Burstable não têm acesso ao pool de conexões PgBouncer integrado.

Parar/iniciar operações

  • Depois de parar a instância flexível do servidor do Banco de Dados do Azure para PostgreSQL, ela é 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 depois de receber a notificação de manutenção não terão impacto na próxima manutenção. As alterações entram em vigor apenas com a seguinte manutenção programada mensal.

Backups do servidor

  • O sistema gerencia backups. No momento, não é possível executar backups manualmente. Recomendamos o uso pg_dump em vez disso.

  • O primeiro snapshot é um backup completo, e snapshots consecutivos são backups diferenciais. Os backups diferenciais fazem backup apenas dos dados alterados desde o último backup de snapshot.

    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 snapshot será de 40 GB. Agora, se você alterar 4 GB de dados, o próximo tamanho de backup de snapshot 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ê estiver usando o recurso de restauração point-in-time (PITR), o sistema cria o novo servidor com as mesmas configurações de computação e armazenamento do servidor no qual ele se baseia.
  • O sistema restaura servidores de banco de dados em redes virtuais nas mesmas redes virtuais quando você restaura a partir de um backup.
  • O novo servidor criado durante uma restauração não tem as regras de firewall que existiam no servidor original. Você precisa criar regras de firewall separadamente para o novo servidor.
  • Não suportamos a restauração para uma assinatura diferente. Como solução alternativa, você pode restaurar o servidor dentro da mesma assinatura e, em seguida, migrar o servidor restaurado para uma assinatura diferente.

Segurança

  • O Postgres 14 e versões posteriores desativam o hash MD5 e o sistema hasha senhas nativas do Postgres usando apenas o método SCRAM-SHA-256.

Conteúdos relacionados

  • Last updated on