Uso de agrupamento de conexões

O Lakebase inclui um pooler de conexões PgBouncer interno que mantém um pool de conexões de servidor e as compartilha em muitas conexões de cliente. O pooler dá suporte a até 10.000 conexões simultâneas, tornando-o uma boa opção para funções sem servidor, APIs Web e outros aplicativos que abrem muitas conexões de curta duração.

O pool de conexões requer autenticação por senha nativa do PostgreSQL. Ele não está disponível para funções de identidade OAuth ou Azure Databricks.

Como funciona o pool de conexões

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

O pooler de conexões fica entre seu aplicativo e o Postgres. Os clientes se conectam ao pooler e o pooler encaminha consultas para um pool menor de conexões de servidor reais. Quando uma transação é concluída, o pooler retorna a conexão do servidor com o pool, disponibilizando-a para o próximo cliente.

O Lakebase executa o PgBouncer no modo de transação. No modo de transação, uma conexão de servidor é mantida durante a duração de uma única transação e retornada para o pool. Isso permite que muitos clientes compartilhem um pequeno pool de conexões de servidor.

O modo de transação melhora a eficiência da conexão, mas restringe determinados recursos do Postgres que exigem uma conexão de servidor persistente. Confira as limitações do modo de transação.

Pools de conexões

O PgBouncer cria um pool separado para cada combinação de banco de dados e usuário. Dois usuários que se conectam ao mesmo banco de dados obtêm pools independentes. O tamanho de cada pool é de aproximadamente 90% do limite de conexão direta da computação.

Quando todas as conexões em um pool estão em uso, novas solicitações de cliente esperam em uma fila. Se uma conexão de servidor não estiver disponível dentro de 2 minutos, o cliente receberá um erro de tempo limite.

Limites de conexão

Três limites regem o pool de conexões:

O limite de conexão direta depende do tamanho da computação. Por exemplo, uma unidade de computação de 8 (UC) dá suporte a 1,678 conexões diretas e uma unidade de computação de 16 (UC) dá suporte a 3,357. Para obter a lista completa, consulte especificações de computação.

O pool de conexões permite que seu aplicativo dê suporte a usuários muito mais simultâneos do que o limite de conexão direta sozinho permitiria.

Pré-requisitos

• Seu projeto Lakebase Autoscaling deve estar ativo.
• Você deve ter uma função de senha do Postgres nativa no projeto. Para obter instruções, consulte Criar uma função de senha nativa do Postgres.
• Para usar o pooler somente leitura, você deve ter um ponto de extremidade de alta disponibilidade com Permitir acesso a instâncias de computação somente-leitura habilitadas. Consulte Alta disponibilidade.

Habilitar o pool de conexões

1. No Aplicativo Lakebase, acesse seu projeto e clique em Conectar.
2. Selecione a ramificação e a computação à qual você deseja se conectar.
3. Na lista suspensa Função , selecione uma função de senha nativa do Postgres. O botão de alternância do pool de conexões só fica visível quando uma função de senha é selecionada. Ele está oculto para funções de identidade OAuth e Azure Databricks.
4. Ative o pool de conexões.
5. Copie o cadeia de conexão e use-o em seu aplicativo.

Formatos de cadeia de conexão

As cadeias de conexão do Pooler usam um nome de host diferente das conexões de banco de dados diretas:

Ambos os tipos de pooler usam a porta 5432.

Limitações do modo de transação

Os seguintes recursos do Postgres não estão disponíveis ao usar o pooler de conexões:

• Instruções preparadas no nível do SQL: PREPARE e DEALLOCATE instruções não têm suporte no modo de transação. As instruções preparadas no nível do driver (usadas internamente pelo psycopg2, node-postgres, JDBC e bibliotecas semelhantes) funcionam corretamente com o suporte em nível de protocolo do PgBouncer. Para o JDBC, se você observar erros relacionados às declarações preparadas, defina prepareThreshold=0 para desabilitar o cache de declarações preparadas nomeadas no lado do servidor.

• Configurações de nível de sessão: SET os comandos não persistem entre transações porque cada transação pode usar uma conexão de servidor diferente. 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 configuração permanentemente, use ALTER ROLE em vez disso:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

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

• WITH HOLD cursores: os cursores declarados com WITH HOLD exigem uma conexão persistente e não têm suporte.

• Bloqueios consultivos: o PgBouncer não dá suporte a bloqueios consultivos. Os bloqueios consultivos exigem uma conexão persistente com o servidor, que não está disponível no modo de transação.

• LISTEN/NOTIFY: sem suporte. Use uma conexão direta (não compartilhada) para aplicativos que necessitam de mensagens pub/sub.

• pg_dump e migrações de esquema: use uma conexão direta para pg_dump, migrações de esquema e outras ferramentas que dependem do estado a nível de sessão.

Próximas Etapas 

• Cadeias de conexão: referência de formato de cadeia de conexão para conexões diretas. Consulte cadeias de conexão.
• Criar funções do Postgres: como criar funções de senha nativas do Postgres necessárias para o pool de conexões. Consulte Criar funções do Postgres.
• Sobre a autenticação: comparação dos métodos de autenticação OAuth e senha. Consulte sobre a autenticação.