Limites no Banco de Dados do Azure para PostgreSQL - Servidor Único

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Único

Importante

O Banco de Dados do Azure para PostgreSQL - Servidor Único está no caminho da desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único PostgreSQL?.

As seções a seguir descrevem os limites funcionais e de capacidade no serviço de banco de dados. Se quiser saber mais sobre os níveis de recursos (computação, memória, armazenamento), consulte o artigo Níveis de preços.

Número máximo de ligações

O número máximo de conexões por camada de preço e vCores é mostrado abaixo. O sistema do Azure requer cinco conexões para monitorar o Banco de Dados do Azure para o servidor PostgreSQL.

Escalão de Preço vCore(s) Conexões máximas Max Conexões de Usuário
Básica 1 55 50
Básica 2 105 100
Fins Gerais 2 150 145
Fins Gerais 4 250 245
Fins Gerais 8 480 475
Fins Gerais 16 950 945
Fins Gerais 32 1500 1495
Fins Gerais 64 1900 1895
Otimizada para Memória 2 300 295
Otimizada para Memória 4 500 495
Otimizada para Memória 8 960 955
Otimizada para Memória 16 1900 1895
Otimizada para Memória 32 1987 1982

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

FATAL: desculpe, muitos clientes já

Importante

Para obter a melhor experiência, recomendamos que você use um pool de conexões como o pgBouncer para gerenciar conexões com eficiência.

Uma conexão PostgreSQL, mesmo ociosa, pode ocupar até 2MB de memória. Além disso, a criação de novas conexões leva tempo. A maioria dos aplicativos solicita muitas conexões de curta duração, o que agrava essa situação. O resultado é menos recursos disponíveis para sua carga de trabalho real, levando a uma diminuição do desempenho. Um pool de conexões que diminui as conexões ociosas e reutiliza as conexões existentes ajudará a evitar isso. Para saber mais, visite nossa postagem no blog.

Limitações funcionais

Operações de escala

  • Atualmente, não há suporte para o dimensionamento dinâmico de e para os níveis de preços básicos.
  • Atualmente, não há suporte para a diminuição do tamanho do armazenamento do servidor.

Atualizações de versão do servidor

  • Atualmente, não há suporte para a migração automatizada entre as principais versões do mecanismo de banco de dados. Se você quiser atualizar para a próxima versão principal, faça um dump e restaure-o para um servidor que foi criado com a nova versão do mecanismo.

Observe que, antes da versão 10 do PostgreSQL, a política de versionamento do PostgreSQL considerava uma atualização de versão principal como um aumento no primeiro ou segundo número (por exemplo, 9.5 para 9.6 era considerada uma atualização de versão principal). A partir da versão 10, apenas uma alteração no primeiro número é considerada uma atualização de versão principal (por exemplo, 10.0 para 10.1 é uma atualização de versão secundária e 10 para 11 é uma atualização de versão principal ).

Pontos finais de serviço da VNet

  • O suporte para pontos de extremidade de serviço VNet é apenas para servidores de uso geral e otimizados para memória.

Restaurar um servidor

  • Ao usar o recurso PITR, o novo servidor é criado com as mesmas configurações de camada de preço do servidor em que se baseia.
  • O novo servidor criado durante uma restauração não tem as regras de firewall que existiam no servidor original. As regras de firewall precisam ser configuradas separadamente para esse novo servidor.
  • Não há suporte para a restauração de um servidor excluído.

Caracteres UTF-8 no Windows

  • Em alguns cenários, os caracteres UTF-8 não são totalmente suportados no PostgreSQL de código aberto no Windows, o que afeta o Banco de Dados do Azure para PostgreSQL. Por favor, veja o tópico sobre o bug #15476 no postgresql-archive para obter mais informações.

Erro GSS

Se vir um erro relacionado com GSS, é provável que esteja a utilizar uma versão do cliente/controlador mais recente que o Servidor Único Postgres do Azure ainda não suporta totalmente. Este erro afeta as versões 42.2.15 e 42.2.16 do controlador JDBC.

  • Planeamos concluir a atualização até ao final de novembro. Entretanto, considere utilizar uma versão funcional do controlador.
  • Ou considere desativar a solicitação do GSS. Utilize um parâmetro de ligação como gssEncMode=disable.

Redução do tamanho do armazenamento

O tamanho do armazenamento não pode ser reduzido. Você precisa criar um novo servidor com o tamanho de armazenamento desejado, executar despejo manual e restaurar e migrar o(s) seu(s) banco(s) de dados para o novo servidor.

Próximos passos