Utilizar o pool de conexões

O Lakebase inclui um pooler de ligações PgBouncer incorporado que mantém um pool de ligações de servidor e as partilha entre várias ligações de clientes. O pooler suporta até 10.000 ligações simultâneas, tornando-o uma boa opção para funções serverless, APIs web e outras aplicações que abrem muitas ligações de curta duração.

O pooling de ligações requer autenticação nativa de senha do Postgres. Não está disponível para funções de identidade OAuth ou Azure Databricks.

Como funciona o pool de conexões

Cada ligação Postgres consome recursos do servidor porque o Postgres cria um processo separado para cada cliente. Aplicações que abrem muitas ligações de curta duração, como APIs web e funções serverless, podem esgotar rapidamente o limite de ligação do servidor.

O pooler de conexão fica entre a tua aplicação e o Postgres. Os clientes ligam-se ao pooler, e o pooler encaminha as consultas para um pool mais pequeno de ligações reais ao servidor. Quando uma transação é concluída, o pooler devolve a ligação do servidor ao pool, tornando-a disponível para o próximo cliente.

A Lakebase executa o PgBouncer em modo de transação. No modo de transação, uma ligação ao servidor é mantida durante a duração de uma única transação e depois devolvida ao pool. Isto permite que muitos clientes partilhem um pequeno conjunto de ligações a servidores.

O modo de transação melhora a eficiência da ligação, mas restringe certas funcionalidades do Postgres que requerem uma ligação persistente ao servidor. Ver limitações do modo de transação.

Pools de conexões

O PgBouncer cria um pool separado para cada base de dados e combinação de utilizadores. Dois utilizadores que se ligam à mesma base de dados obtêm pools independentes. O tamanho de cada pool é aproximadamente 90% do limite de ligação direta do cálculo.

Quando todas as ligações de um pool estão em uso, novos pedidos de clientes aguardam numa fila. Se uma ligação ao servidor não ficar disponível dentro de 2 minutos, o cliente recebe um erro de timeout.

Limites de ligação

Três limites regem o agrupamento de ligações:

O limite de ligação direta depende do tamanho do seu cálculo. Por exemplo, uma unidade de computação de 8 CU suporta 1.678 ligações diretas e uma unidade de computação de 16 CU suporta 3.357. Para a lista completa, veja Especificações de Computação.

O pool de conexões permite que a sua aplicação suporte muitos mais utilizadores concorrentes do que permitiria o limite de conexão direta.

Pré-requisitos

• O seu projeto de Autoscaling da Lakebase tem de estar ativo.
• É necessário ter uma função de senha nativa do Postgres no projeto. Para instruções, consulte Criar uma palavra-passe nativa do Postgres.
• Para usar o pooler de apenas leitura, deve ter um endpoint de alta disponibilidade com permitir acesso a instâncias de computação apenas de leitura ativado. Ver Alta disponibilidade.

Permitir o agrupamento de ligações

1. Na aplicação Lakebase, aceda ao seu projeto e clique em Conectar.
2. Seleciona o ramo e a computação a que te queres ligar.
3. No menu suspenso de Funções , selecione uma função nativa de palavra-passe Postgres. A opção Pooling de Conexões só é visível quando uma função de palavra-passe é selecionada. Está oculto para os roles de identidade OAuth e Azure Databricks.
4. Ativar pool de conexões.
5. Copia a cadeia de ligação e usa-a na tua aplicação.

Formatos de cadeia de conexão

As cadeias de ligação do pooler usam um nome de host diferente das ligações diretas à base de dados:

Ambos os tipos de pooler usam a porta 5432.

Limitações do modo de transação

As seguintes funcionalidades do Postgres não estão disponíveis ao usar o pooler de ligações:

• Instruções preparadas ao nível SQL: PREPARE e DEALLOCATE instruções não são suportadas em modo de transação. As instruções preparadas ao nível do driver (usadas internamente pelo psycopg2, node-postgres, JDBC e bibliotecas semelhantes) funcionam corretamente graças ao suporte de nível de protocolo do PgBouncer. Para JDBC, se vires erros relacionados com instruções preparadas, configura prepareThreshold=0 para desativar a cache de instruções preparadas nomeadas do lado do servidor.

• Definições ao nível da sessão: SET os comandos não persistem entre transações porque cada transação pode usar uma ligação diferente ao servidor. Por exemplo:

  BEGIN;
  SET search_path TO myschema;
  SELECT * FROM mytable; -- works in this transaction
  COMMIT;
  -- connection returns to pool after COMMIT
  SELECT * FROM mytable; -- ERROR: relation "mytable" does not exist
  

  Para aplicar uma definição permanentemente, use ALTER ROLE em vez disso:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Tabelas temporárias realizadas em sessões: Tabelas temporárias que persistem entre transações não estão disponíveis. Uma ligação devolvida ao pool pode ser atribuída a um cliente diferente na próxima transação.

• WITH HOLD cursores: Os cursores declarados com WITH HOLD requerem uma ligação persistente e não são suportados.

• Bloqueios de aviso: O PgBouncer não suporta bloqueios de aviso. Os bloqueios de aviso exigem uma ligação persistente ao servidor, que não está disponível no modo de transação.

• LISTEN/NOTIFY: Não suportado. Utilize uma ligação direta (não partilhada) para aplicações que requerem mensagens de publicação/assinatura.

• pg_dump e migrações de esquema: Use uma ligação direta para pg_dump, migrações de esquema e outras ferramentas que dependam do estado ao nível da sessão.

Passos seguintes

• Cadeias de conexão: Referência de formato de cadeia de conexão para conexões diretas. Ver cadeias de conexão.
• Criar funções Postgres: Como criar funções nativas de palavra-passe Postgres necessárias para pooling de ligações. Ver Criar funções de Postgres.
• Sobre autenticação: Comparação entre métodos OAuth e autenticação por palavra-passe. Veja Sobre autenticação.