Visão geral do agrupamento de conexões gerenciado

O pooling de conexões gerenciado permite escalonar as cargas de trabalho otimizando o uso de recursos e a latência de conexão das instâncias do Cloud SQL. Ele atribui dinamicamente conexões de servidor a solicitações recebidas quando possível. Essa atribuição dinâmica oferece melhorias de desempenho, especialmente para conexões escalonadas, absorvendo picos repentinos de conexão e reutilizando conexões de banco de dados existentes.

O pooling de conexões gerenciado se conecta a um cluster de poolers em vez de um banco de dados específico. Em seguida, o pooler gerencia as conexões recebidas com o banco de dados. Isso oferece tempos de conexão mais curtos e escalonabilidade para suas cargas de trabalho. Cada pool está associado a um banco de dados e um usuário exclusivos. Depois que um cliente é autenticado, o pool reutiliza uma conexão de servidor inativa dentro do pool para conectar o banco de dados ao servidor. Se uma conexão de servidor não estiver disponível, ela criará uma nova conexão de servidor no pool para conectar o banco de dados. O número de poolers usados é baseado no número de núcleos de vCPU da instância.

Casos de uso e considerações

Lembre-se do seguinte ao usar o pooling de conexões gerenciado:

  • Embora seja possível usar o pooling de conexões gerenciado para qualquer carga de trabalho transacional, ele oferece o maior benefício de capacidade de processamento e latência para aplicativos que contêm conexões de curta duração ou que resultam em um aumento de conexão.
  • Para conexões de longa duração, o desempenho da conexão usando o pooling de conexões gerenciado pode ser ligeiramente menor do que ao usar uma conexão direta. Nesse caso, o pooling de conexões gerenciado fornece escalonamento de conexão quando o número de conexões é muito alto. No entanto, para aplicativos que normalmente estabelecem conexões de longa duração, talvez seja melhor evitar o uso do pooling de conexões.
  • É possível usar o Identity and Access Management para proteger conexões com a instância, dependendo de porta usada pelo pooling de conexões gerenciado. Para mais informações sobre como o IAM funciona no Cloud SQL e as limitações dele, consulte Autenticação do IAM.

Para mais informações sobre como ativar o pooling de conexões gerenciado, consulte Configurar o pooling de conexões gerenciado.

Requisitos

Para usar o pooling de conexões gerenciado, a instância precisa atender aos seguintes requisitos:

  • A instância precisa ser uma instância da edição Cloud SQL Enterprise Plus.
  • Você precisa estar conectado à instância usando apenas uma conexão direta ou o proxy do Cloud SQL Auth.
  • A instância precisa ser configurada para acesso a serviços privados, usar IP público ou ser uma nova instância com o Private Service Connect ativado.
  • A instância precisa usar a nova arquitetura de rede do Cloud SQL.
  • O pooling de conexões gerenciado exige um número mínimo de versão de manutenção de POSTGRES_$version.R20250727.00_14. Para mais informações sobre como realizar a manutenção de autoatendimento, consulte Realizar a manutenção de autoatendimento.

Opções de pooling

O pooling de conexões gerenciado permite gerenciar como as conexões são agrupadas usando o parâmetro pool_mode. Você pode usar as seguintes opções de pooling:

  • transaction (padrão): agrupa conexões em um nível de transação. As conexões são retornadas ao pool após a conclusão de cada transação. O Cloud SQL recomenda o uso do modo de pooling transaction para conexões de curta duração.
  • session: agrupa conexões em um nível de sessão. Cada sessão usa uma conexão de servidor dedicada que mantém um estado de sessão. Isso reduz a eficiência do pooling. Quando um cliente se desconecta, a conexão do servidor retorna ao pool de conexões.

Opções de configuração avançada

É possível personalizar o pooling de conexões gerenciado usando as seguintes opções de configuração:

Nome da configuração Descrição
max_pool_size O número máximo de conexões de servidor permitidas para um par de banco de dados e usuário em cada pool de conexões. O valor padrão é de 50 conexões.
min_pool_size O número mínimo de conexões de servidor disponíveis a qualquer momento em cada pool de conexões.

Se o número de conexões de servidor for menor que o min_pool_size, essa configuração vai adicionar mais conexões de servidor ao pool. Isso ajuda a gerenciar aumentos repentinos na carga do banco de dados após períodos de inatividade e garante que as conexões estejam disponíveis e prontas para uso.

O valor padrão é de 0 conexões.
max_client_connections O número máximo de conexões permitidas para a instância ao usar o pooling de conexões gerenciado. O valor padrão é de 5.000 conexões.
max_prepared_statements O número máximo de instruções preparadas nomeadas no nível do protocolo com suporte em transaction modo de pooling.

Definir essa opção como 0 desativa o suporte a instruções preparadas. Para um desempenho ideal, esse valor precisa exceder o número de instruções preparadas usadas com frequência no banco de dados. Um grande número de instruções preparadas no pooling de conexões gerenciado cmay cause an increase in uso da memória.

O valor padrão é de 0 instruções.
client_connection_idle_timeout O tempo que uma conexão de cliente permanece inativa antes de atingir o tempo limite. Esse valor pode variar de 0 a 2.147.483 segundos, e o valor padrão é de 0 segundos.
server_connection_idle_timeout O tempo que uma conexão de servidor permanece inativa antes de atingir o tempo limite. Este valor pode variar de 0 a 2.147.483 segundos, e o valor padrão é de 600 segundos.
query_wait_timeout O tempo que uma consulta aguarda uma conexão de servidor em um pool antes de atingir o tempo limite.

Definir essa opção como 0 a desativa, o que permite o enfileiramento indefinido de clientes Ativar essa opção impede que servidores sem resposta mantenham conexões.

Esse valor pode variar de 0 a 2.147.483 segundos, e o valor padrão é de 120 segundos.
ignore_startup_parameters Os parâmetros que você quer ignorar e que não são rastreados nos pacotes de inicialização do pooling de conexões gerenciado por padrão.
server_lifetime O tempo máximo que uma conexão de servidor fica sem uso antes que o pooling de conexões gerenciado feche. Se o valor for definido como 0 segundos, a conexão será fechada imediatamente após o uso.

O valor padrão é de 3.600 segundos.

Limitações

Ao usar o pooling de conexões gerenciado com as instâncias da edição Cloud SQL Enterprise Plus, considere estas limitações:

  • Ativar o pooling de conexões gerenciado em uma instância resulta em uma reinicialização do banco de dados.
  • O pooling de conexões gerenciado só pode ser usado com o proxy do Cloud SQL Auth versão 2.15.2 e mais recentes.
  • Se você estiver usando o conector de linguagem Go do Cloud SQL, recomendamos uma versão mínima do Go de 1.24. Se você usar a versão 1.23 ou anterior do Go, poderá ter limitações de desempenho ao usar o pooling de conexões gerenciado.

  • Se você estiver usando o pooling de conexões gerenciado no modo de pooling transaction, os seguintes recursos de SQL não serão compatíveis:

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • Tabelas temporárias PRESERVE/DELETE ROW
    • LOAD
    • Bloqueios consultivos no nível da sessão

  • Se você estiver usando a biblioteca de interface de banco de dados asyncpg para o pooler de pooling de conexões gerenciado nas portas 3307 e 6432, será necessário atualizar o max_prepared_statements para um valor maior que 0 para ativar o suporte a instruções preparadas no pooler de pooling de conexões gerenciado.

  • Se você estiver usando o Cloud SQL para PostgreSQL versão 17, a opção sslnegotiation=direct não será compatível.

  • O rastreamento de IP do cliente não é compatível com o pooling de conexões gerenciado. Se você ativar Armazenar endereços IP do cliente em Query Insights, os endereços IP do cliente serão exibidos como local em vez do endereço IP em si.

Portas usadas pelo pooling de conexões gerenciado

Quando você ativa o pooling de conexões gerenciado, as portas usadas pelas instâncias do Cloud SQL para veicular o tráfego do banco de dados mudam. É possível usar o Identity and Access Management para proteger conexões, dependendo da porta.

As portas usadas pelo pooling de conexões gerenciado e as opções de IAM disponíveis são as seguintes:

Conexões de servidor usadas pelo pooling de conexões gerenciado

A configuração de banco de dados max_connections limita o número máximo de conexões de servidor que um pooler no pooling de conexões gerenciado pode usar. O Cloud SQL recomenda ajustar esse valor com base nos requisitos de carga de trabalho da instância e no tamanho da instância do banco de dados. Durante o pico de carga, o número de conexões para autenticação pode ficar muito alto.

Se você estiver usando o max_pool_size padrão de 50 pools na instância, recomendamos reservar pelo menos 15 conexões de servidor por CPU para o pooling de conexões gerenciado ao definir a flag max_connections para o banco de dados. Para mais informações sobre a flag max_connections, consulte Máximo de conexões simultâneas. Para modificar a flag max_connections da instância, consulte Configurar flags do banco de dados.

A seguir