Utilize o agrupamento de conexões.

Lakebase inclui um gerenciador de conexões PgBouncer integrado que mantém um pool de conexões de servidor e as compartilha entre várias conexões de clientes. O pool de conexões suporta até 10.000 conexões simultâneas de clientes, sendo uma boa opção para funções serverless , APIs da web e outras aplicações que abrem muitas conexões de curta duração.

O agrupamento de conexões requer autenticação nativa por senha do Postgres. Não está disponível para funções OAuth.

Como funciona o agrupamento de conexões

Cada conexão Postgres consome recursos do servidor porque o Postgres cria um processo separado para cada cliente. À medida que o número de conexões simultâneas aumenta, o limite de conexões do servidor pode se esgotar rapidamente.

O gerenciador de conexões fica entre sua aplicação e o Postgres. Os clientes se conectam ao pooler, e o pooler encaminha as consultas para um pool menor de conexões reais do servidor. Lakebase executa o PgBouncer em modo transacional, portanto, uma conexão com o servidor é mantida apenas durante a duração de uma única transação e, em seguida, devolvida ao pool. Isso permite que muitos clientes compartilhem um pequeno pool de conexões de servidor.

Piscina 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 é aproximadamente 90% do limite do Postgres max_connections , que varia de acordo com o tamanho compute .

Quando todas as conexões em um pool estão em uso, as novas solicitações do cliente ficam aguardando em uma fila. Se uma conexão com o servidor não estiver disponível em 2 minutos, o cliente recebe um erro de tempo limite excedido.

O diagrama mostra como várias conexões de clientes de diferentes usuários são roteadas por meio de pools PgBouncer separados (um para cada combinação de usuário/banco de dados), que compartilham um número limitado de conexões Postgres reais.

Limites de conexão

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

Limite	Valor	O que ele controla
Conexões de clientes (max_client_conn)	10.000	Conexões máximas do seu aplicativo para o PgBouncer
tamanho da piscina (default_pool_size)	~90% de max_connections	Conexões de servidor ativas por par (usuário, banco de dados)
Conexões diretas (max_connections)	Varia de acordo com o tamanho compute .	Número máximo de conexões diretas com o Postgres

O limite de conexões diretas depende da capacidade compute da sua empresa. Por exemplo, um compute 8 CUs suporta 1.678 conexões diretas e um compute 16 CUs suporta 3.357. Para a lista completa, consulte as especificações de computação.

O limite de 10.000 conexões de clientes não significa 10.000 resultados de consultas simultâneas. Representa o número máximo de conexões de clientes que o PgBouncer aceita. O número de transações ativas concorrentes é limitado pelo tamanho pool , que é aproximadamente 90% de max_connections.

Ativar o agrupamento de conexões

Pré-requisitos

• Seu projeto de autoescalonamento Lakebase precisa estar ativo.
• Você precisa ter uma função nativa de senha do Postgres no projeto. Para obter instruções, consulte Criar uma função de senha nativa do Postgres.
• Para usar o pool de conexões com instâncias compute somente leitura, você precisa ter um endpoint de alta disponibilidade com a opção "Permitir acesso a instâncias compute somente leitura" habilitada. Veja Alta disponibilidade.

os passos

1. No aplicativo Lakebase, acesse seu projeto e clique em Conectar .
2. Selecione a filial e compute aos quais deseja se conectar.
3. Na lista suspensa "Função" , selecione uma função de senha nativa do Postgres. A opção de agrupamento de conexões só fica visível quando uma função de senha é selecionada. Está oculto para funções OAuth.
4. Ative o agrupamento de conexões .
5. Copie as strings de conexão e utilize-as em sua aplicação.

Formatos de cadeias de conexão

strings de conexão do Pooler usam um hostname diferente das conexões diretas com o banco de dados. O hostname inclui -pooler após o ID endpoint para compute de leitura e gravação, ou -ro-pooler para compute somente leitura:

Tipo de Compute	formato de nome de host	Quando usar
computede leitura e escrita	<endpoint-id>-pooler.<region>.<cloud>.databricks.com	Todo o tráfego de leitura e escrita
computesomente leitura	<endpoint-id>-ro-pooler.<region>.<cloud>.databricks.com	Somente leitura de tráfego. Requer um endpoint de alta disponibilidade com acesso de leitura habilitado.

Ambos utilizam a porta 5432.

nota

Copie as strings de conexão do pooler diretamente da caixa de diálogo Conectar no aplicativo Lakebase para obter o hostname correto para seu endpoint, região e cloud.

Configuração do PgBouncer

Lakebase gerencia PgBouncer com as seguintes configurações. Essas configurações são fixas e não podem ser personalizadas.

ini

[pgbouncer]
pool_mode=transaction
max_client_conn=10000
default_pool_size=0.9 * max_connections
max_prepared_statements=1000
query_wait_timeout=120

Contexto	Descrição
pool_mode=transaction	As conexões do servidor retornam ao pool após cada transação. Consulte o modo de transação.
max_client_conn=10000	Número máximo de conexões simultâneas de clientes que o PgBouncer aceita.
default_pool_size=0.9 * max_connections	Conexões ativas do servidor por par (usuário, banco de dados). Varia de acordo com o tamanho compute .
max_prepared_statements=1000	Permite instruções preparadas em nível de protocolo no modo de transação. Limita o número de declarações rastreadas a 1.000 por conexão de cliente.
query_wait_timeout=120	Segundos que um cliente aguarda por uma conexão com o servidor antes de receber um erro de tempo limite.

Modo de transação

O modo de transação melhora a eficiência da conexão, mas restringe certos recursos do Postgres que exigem uma conexão persistente com o servidor. Os seguintes recursos não estão disponíveis ao usar o pool de conexões:

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

• Configurações de nível de sessão : o comando SET não persiste entre transações porque cada transação pode usar uma conexão de servidor diferente. Por exemplo:

  SQL

  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:

  SQL

  ALTER ROLE myrole SET search_path TO myschema, public;

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

• CursoresWITH HOLD : Cursores declarados com WITH HOLD requerem uma conexão persistente e não são suportados.

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

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

• 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 em nível de sessão.

nota

Para aplicações que requerem recursos do Postgres em nível de sessão, utilize strings de conexão diretas a partir da caixa de diálogo Conectar , sem habilitar a opção de pool de conexões .