O pool de conexões gerenciado permite escalonar suas cargas de trabalho otimizando o uso de recursos e a latência de conexão das instâncias do Cloud SQL. O PostgreSQL cria um novo processo para cada conexão, o que gera uso da memória e sobrecarga de configuração de conexão. Em arquiteturas que estabelecem muitas conexões de curta duração com frequência, como microsserviços ou aplicativos sem servidor em execução no Cloud Run, essa sobrecarga pode afetar o desempenho e a escalonabilidade do banco de dados.
Com o pool de conexões gerenciado ativado, os clientes se conectam a um cluster de pool de conexões intermediário em vez de se conectar diretamente ao servidor de banco de dados. 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 atuais.
Poolers de conexão e pools de conexão
Quando os aplicativos cliente se conectam a uma instância com o pool de conexões gerenciado ativado, eles se conectam a um cluster de pool de conexões intermediário em vez de se conectar diretamente ao servidor de banco de dados. O cluster de pool de conexões consiste em um ou mais poolers de conexão. Um pooler de conexão é um serviço de proxy de banco de dados que gerencia e encaminha conexões de banco de dados entre aplicativos cliente e o servidor de banco de dados.
Um pooler de conexão mantém pools de conexão como um grupo de conexões de servidor de banco de dados reutilizáveis abertas por banco de dados e par de usuários.
Quando um aplicativo cliente autenticado se conecta a um banco de dados como um usuário específico, o pooler de conexão encaminha a solicitação para o pool de conexões correspondente:
- Se uma conexão de servidor inativa estiver disponível no pool, o pooler de conexão a atribuirá à solicitação do cliente.
- Se uma conexão de servidor inativa não estiver disponível e o limite do pool (
max_pool_size) não tiver sido atingido, o pooler de conexão criará uma nova conexão de servidor no pool. - Se todas as conexões de servidor no pool estiverem em uso e o limite do pool tiver sido atingido, o cliente fará a transição para um estado de espera até que uma conexão de servidor fique disponível.
- Quando a solicitação terminar, a conexão do servidor retornará ao pool de conexões para reutilização.
Relação entre poolers e pools
Um único pooler de conexão pode gerenciar vários pools de conexão simultaneamente, com um pool para cada banco de dados exclusivo e par de usuários de banco de dados que se conecta por esse pooler.
Se a instância executar vários poolers de conexão, cada um deles manterá de forma independente o próprio conjunto de pools de conexão para o banco de dados e os pares de usuários encaminhados a ele.
O desempenho e os recursos de escalonamento do pool de conexões gerenciado operam em vários níveis:
Escalonamento do cluster de pool de conexões:o número de poolers de conexão no cluster é escalonado automaticamente com base no número de núcleos de vCPU provisionados para a instância (dividindo a contagem de vCPU por 4, com um mínimo de 1 pooler de conexão). Isso garante que o pool de conexões não se torne um gargalo. As conexões de cliente recebidas são distribuídas entre os poolers de conexão disponíveis. Exemplo:
- Uma instância com 2 ou 4 vCPUs executa 1 pooler de conexão.
- Uma instância com 8 vCPUs executa 2 poolers de conexão.
- Uma instância com 16 vCPUs executa 4 poolers de conexão.
- Uma instância com 32 vCPUs executa 8 poolers de conexão.
- Uma instância com 64 vCPUs executa 16 poolers de conexão.
Escalonamento de pooler e pool:como os poolers de conexão operam de forma independente, todas as opções de configuração são aplicadas por pooler de conexão, em vez de globalmente na instância. As conexões de servidor são criadas sob demanda até um limite máximo definido por
max_pool_sizepara cada pool gerenciado em cada pooler de conexão. Por exemplo, semax_pool_sizeestiver definido como 50 em uma instância que executa 2 poolers de conexão (8 vCPUs), cada pooler de conexão poderá abrir até 50 conexões de servidor para um banco de dados específico e um par de usuários, permitindo um total de até 100 conexões de servidor na instância para esse pool. O dimensionamento preciso do pool é essencial para o desempenho: definir esse valor muito baixo pode levar a tempos de espera de conexão mais longos, enquanto defini-lo muito alto pode desperdiçar recursos do servidor de banco de dados.Configurações de conexão do cliente:os limites de conexão do cliente e o comportamento de tempo limite também são configurados por pooler de conexão. Os principais parâmetros incluem:
max_client_connections: limita o número máximo de conexões de cliente permitidas por pooler de conexão (o valor padrão é 5.000 conexões para cada pooler de conexão).client_connection_idle_timeout: controla a duração que uma conexão de cliente pode permanecer inativa antes de atingir o tempo limite.query_wait_timeout: controla a duração que uma consulta espera por uma conexão de servidor disponível no pool antes de atingir o tempo limite.
Casos de uso e considerações
Considere o seguinte ao usar o pool de conexões gerenciado:
- Embora seja possível usar o pool 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 pool de conexões gerenciado pode ser ligeiramente menor do que ao usar uma conexão direta. Nesse caso, o pool 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 pool de conexões.
- É possível usar o Identity and Access Management para proteger conexões com sua instância, dependendo da porta usada pelo pool de conexões gerenciado. Para mais informações sobre como o IAM funciona no Cloud SQL e suas limitações, consulte Autenticação do IAM.
Para mais informações sobre como ativar o pool de conexões gerenciado, consulte Configurar o pool de conexões gerenciado.
Requisitos
Para usar o pool 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 de autenticação do Cloud SQL.
- A instância precisa ser configurada para acesso a serviços privados, usar IP público ou ter o Private Service Connect ativado.
- A instância precisa usar a nova arquitetura de rede do Cloud SQL.
- O pool 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 pool 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 poolingtransactionpara 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 pool 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 banco de dados e um par de usuários
em cada pool de conexões. Essa configuração é aplicada por
pooler de conexão. Determine esse valor com base nos requisitos de tamanho da instância e
do pool.
O valor padrão é 50 conexões por banco de dados e
par de usuários para cada pooler de conexão.
|
min_pool_size
|
O número mínimo de conexões de servidor disponíveis a qualquer momento em cada
pool de conexões. Essa configuração é aplicada por pooler de conexão.
Determine esse valor com base nos requisitos de tamanho da instância e do pool.
Se o número de conexões de servidor for menor que o min_pool_size, essa configuração 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 é 0 conexões.
|
max_client_connections
|
O número máximo de conexões de cliente permitidas por pooler de conexão
ao usar o pool de conexões gerenciado. Determine esse valor com base
nos requisitos de tamanho da instância e do pool.
O valor padrão é 5,000 conexões para cada pooler de conexão.
|
max_prepared_statements
|
O número máximo de instruções preparadas nomeadas no nível do protocolo
com suporte por pooler de conexão no
transaction modo de pooling.
Determine esse valor com base nos requisitos de tamanho da instância e do pool.
Definir essa opção como 0 desativa o suporte a instruções preparadas
support. 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 pool de conexões gerenciado pode causar um
aumento no uso da memória.
O valor padrão é 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 é 0 segundos.
|
server_connection_idle_timeout
|
O tempo que uma conexão de servidor permanece inativa antes de atingir o tempo limite.
Esse valor pode variar de 0 a 2,147,483 segundos, e o valor padrão é 600 segundos.
|
query_wait_timeout
|
O tempo que uma consulta espera por 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 é 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 pool 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 pool de conexões gerenciado a feche. Se o valor for definido como
0 segundos, a conexão será fechada imediatamente
após o uso.
O valor padrão é 3600 segundos.
|
Limitações
Ao usar o pool de conexões gerenciado com as instâncias da edição Cloud SQL Enterprise Plus, considere estas limitações:
- A ativação do pool de conexões gerenciado em uma instância atual resulta em uma reinicialização do banco de dados.
- O pool de conexões gerenciado só pode ser usado com o proxy de autenticação do Cloud SQL 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 pool de conexões gerenciado. Se você estiver usando o pool de conexões gerenciado no modo de pooling
transaction, os seguintes recursos de SQL não serão compatíveis:SET/RESETLISTENWITH HOLD CURSORPREPARE/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 pool de conexões gerenciado nas portas 3307 e 6432, será necessário atualizar o
max_prepared_statementspara um valor maior que 0 para ativar o suporte a instruções preparadas no pooler de pool de conexões gerenciado.Se você estiver usando o Cloud SQL para PostgreSQL versão 17, a opção
sslnegotiation=directnão será compatível.O rastreamento de IP do cliente não é compatível com o pool 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
localem vez do endereço IP em si.
Portas usadas pelo pool de conexões gerenciado
Quando você ativa o pool 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 pool de conexões gerenciado e as opções de IAM disponíveis são as seguintes:
Porta TCP
5432: usada para conexões diretas pelo banco de dados do Postgres servidor. Esse é o número da porta padrão para conexão direta usando o cliente psql.Porta TCP
6432: usada para conexões diretas pelo servidor de pool de conexões gerenciado. Para se conectar usando essa porta, especifiquepsql -p 6432ao se conectar diretamente usando o cliente psql.É possível usar qualquer opção de autenticação do IAM ao usar essa porta.
Porta TCP
3307: usada para conexões somente do proxy de autenticação do Cloud SQL por um servidor de pool de conexões gerenciado. Ao usar o proxy de autenticação do Cloud SQL para se conectar ao pool de conexões gerenciado, esse número de porta é configurado com o cliente do proxy de autenticação do Cloud SQL e não pode ser alterado.É possível usar qualquer opção de autenticação do IAM, ou a autenticação automática do banco de dados do IAM com essa porta.
Conexões de servidor usadas pelo pool 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 pool 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 conexões por pool, recomendamos reservar pelo menos 15 conexões de servidor por CPU para o pool 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
Número máximo de conexões simultâneas.
Para modificar a flag max_connections da instância,
consulte Configurar flags do banco de dados.