Limites na Base 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 Banco de Dados do Azure para o servidor flexível PostgreSQL. Se quiser saber mais sobre as camadas de recursos (computação, memória ou armazenamento), consulte o artigo 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. 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 de servidor flexível do Banco de Dados do Azure para PostgreSQL. Consequentemente, o valor para o máximo de conexões de usuário listado 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 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_connectionssuperuser_reserved_connections).

O valor padrão para o max_connections parâmetro server é calculado 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 da seleção de produtos para a computação que suporta o servidor flexível não terão qualquer 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 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. Este número é baseado na configuração do seu servidor e não pode ser alterado.

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 - Servidor Flexível.

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

FATAL: sorry, too many clients already.

Quando você estiver usando o Banco de Dados do Azure para servidor flexível 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.

Lembre-se de que cada conexão no Banco de Dados do Azure para servidor flexível 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, consulte Identificar e resolver o desempenho da conexão no Banco de Dados do Azure para servidor flexível PostgreSQL.

Limitações funcionais

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

Operações de escala

  • Neste momento, a expansão do armazenamento do servidor requer uma reinicialização do servidor.
  • Você pode dimensionar o armazenamento do servidor somente em incrementos de 2x. Para obter detalhes, consulte Computação e armazenamento.

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 é inferior a 5 GiB (o que for maior), o servidor é 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 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), 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 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. O servidor flexível do Banco de Dados do Azure para PostgreSQL usa o padrão herdado do banco de dados de modelo. 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).

Rede

  • Atualmente, não há suporte para entrar e sair de uma rede virtual.
  • Atualmente, não há suporte para a combinação de acesso público com implantação em uma rede virtual.
  • As regras de firewall não são suportadas em redes virtuais. 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 há suporte para mover manualmente 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

  • Postgres 10 e versões mais antigas não são suportadas, porque a comunidade de código aberto os aposentou. Se você precisar usar uma dessas versões, precisará usar a opção de servidor único do Banco de Dados do Azure para PostgreSQL, que dá suporte às 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 contrib extensões e muito mais. Para obter mais informações, consulte Extensões PostgreSQL.
  • O pool de conexões PgBouncer integrado não está disponível para servidores Burstable no momento.

Parar/iniciar operações

  • Depois de parar a instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, ela é iniciada 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 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. Atualmente, não há como 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 novo servidor é criado com as mesmas configurações de computação e armazenamento do servidor no qual ele 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 tem as regras de firewall que existiam no servidor original. Você precisa criar regras de firewall separadamente para o novo servidor.
  • Não há suporte para restaurar 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.

Próximos passos