Session-level connection pools and transaction-level connection pools of PolarDB - PolarDB: Central de Documentação do Alibaba Cloud

O PolarDB oferece dois tipos de pool de conexões: nível de sessão e nível de transação. Os pools de conexões reduzem a sobrecarga de conexões com o banco de dados ao reutilizar conexões existentes em vez de estabelecer novas para cada solicitação.

O pool de conexões descrito aqui é um recurso do PolarProxy, a camada de proxy do PolarDB. Ele não afeta nenhum pool de conexões integrado à sua aplicação. Se a sua aplicação já gerencia seu próprio pool de conexões, não é necessário ative esse recurso.

Como funciona

Pool de conexões no nível de sessão

Session-level connection pool diagram

Quando uma conexão da aplicação é fechada, o PolarProxy verifica se ela está ociosa. Nesse caso, o PolarProxy a retém no pool por um curto período. A próxima solicitação recebida reutiliza essa conexão ociosa se os parâmetros user, clientip e dbname coincidirem, evitando o custo de abrir uma nova conexão. Caso não haja correspondência, o PolarProxy abre uma nova conexão com o banco de dados.

Os pools no nível de sessão reduzem a frequência de estabelecimento de conexões, o que diminui o número de threads principais do MySQL consumidas e melhora o throughput. Eles não reduzem o número total de conexões simultâneas; as conexões ociosas ainda contam para o limite de conexões do banco de dados.

Pool de conexões no nível de transação

Transaction-level connection pool diagram

Um pool no nível de transação reduz tanto o número de conexões diretas com o banco de dados quanto a sobrecarga causada por conexões de curta duração. As aplicações podem abrir milhares de conexões com o PolarProxy, enquanto este mantém apenas dezenas ou centenas de conexões com os bancos de dados de back-end.

Ao receber uma solicitação da aplicação, o PolarProxy não abre imediatamente uma conexão de back-end. Ele verifica no pool se existe uma conexão ociosa que corresponda aos parâmetros user, dbname e às variáveis de sistema (sql_mode, character_set_server, collation_server, time_zone). Se houver correspondência, o PolarProxy a reutiliza. Após a conclusão da transação, a conexão retorna ao pool para atender a outras solicitações.

O PolarProxy não impõe limite de contagem de conexões no lado da aplicação. O número máximo de conexões para um endpoint de cluster do PolarDB depende das especificações dos nós de computação de back-end. Sem um pool no nível de transação, o sistema precisa abrir uma conexão separada no nó primário e em cada nó somente leitura para cada solicitação.

Escolha um pool de conexões

Use esta tabela para identificar o tipo de pool adequado ao seu cenário:

Cenário	Pool recomendado	Motivo
Poucas conexões, majoritariamente persistentes, ou aplicação com pool próprio	Nenhum (desativar)	Um pool do PolarDB adiciona sobrecarga sem trazer benefícios
Dezenas de milhares de conexões, ou serverless com conexões que escalam linearmente	Nível de transação	Multiplexa muitas conexões da aplicação em menos conexões de back-end
Apenas conexões de curta duração, nos cenários listados em Limitações do nível de transação	Nível de sessão	Reduz a frequência de conexões sem exigir multiplexação completa
Execução frequente de `COM_STATISTICS`	Nenhum (desativar)	Ative o pool converte conexões não persistentes em persistentes, aumentando o número de conexões persistentes e desencadeando um gargalo de bloqueio e travessia no `COM_STATISTICS`. Execuções frequentes podem causar degradação grave de desempenho e afetar o tempo de resposta geral do negócio.
Grande volume de instruções SQL lentas causando conexões pendentes	Nenhum (desativar)	Pools de conexões não resolvem contenção por consultas lentas; reduza as consultas lentas em vez disso

Limitações

Limitações do nível de sessão

Os pools no nível de sessão reduzem a frequência de conexões, não a concorrência. Conexões ociosas no pool ainda contam para o limite total de conexões do banco de dados.
Pools no nível de sessão não resolvem conexões pendentes causadas por instruções SQL lentas.

Limitações do nível de transação

As operações a seguir bloqueiam a conexão durante toda a sessão. Uma conexão bloqueada não retorna ao pool e fica indisponível para outras solicitações.

Operação	Solução alternativa
Execute uma instrução `PREPARE`	Use prepared statements no lado do cliente se o driver oferecer suporte
Crie uma tabela temporária	Utilize uma tabela regular com um identificador de sessão exclusivo e exclua-a ao terminar
Modifique variáveis de usuário	Defina as variáveis no início da sessão ou passe os valores explicitamente em cada consulta
Receber entradas de log superiores a 16 MB	Divida gravações grandes de log em lotes menores
Execute uma instrução `LOCK TABLE`	Prefira bloqueio no nível de linha (`SELECT ... FOR UPDATE`)
Execute múltiplas instruções em uma única string de instrução	Separe-as em instruções individuais
Chamar um stored procedure	Migre a lógica para a camada da aplicação sempre que possível

Funções não suportadas

É possível chamar FOUND_ROWS(), ROW_COUNT() e LAST_INSERT_ID(), mas elas podem retornar resultados imprecisos quando as conexões são reutilizadas.

Função	Solução alternativa
`FOUND_ROWS()`	No PolarProxy V1.13.11 ou posterior, coloque `SELECT FOUND_ROWS()` imediatamente após `SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT `. Observe que esse método não é mais recomendado pelo MySQL open source. Como alternativa, substitua-o por `SELECT COUNT() FROM tb1`. Para mais detalhes, consulte FOUND_ROWS().
`LAST_INSERT_ID()`	Coloque `SELECT LAST_INSERT_ID()` imediatamente após a instrução `INSERT` para obter resultados precisos.
`ROW_COUNT()`	Não há solução alternativa disponível; a função pode ser invocada, mas pode retornar resultados imprecisos quando as conexões são reutilizadas.

Outras diferenças comportamentais

wait_timeout: Quando o tempo limite expira, apenas as conexões de back-end são fechadas. As conexões da aplicação com o PolarProxy permanecem abertas porque o PolarProxy selecione uma conexão do pool para cada nova solicitação.
Variáveis de sessão: O pool faz a correspondência de conexões usando sql_mode, character_set_server, collation_server e time_zone. Se suas solicitações dependem de outras variáveis de sistema no nível de sessão, execute instruções SET para configurá-las após o estabelecimento de cada conexão. Caso contrário, o pool poderá reutilizar uma conexão com valores inesperados para as variáveis.
Nível de isolamento: Mantenha o nível de isolamento padrão READ COMMITTED. Se um cliente alterar explicitamente o nível de isolamento, a conexão retornará ao pool após o término da transação e poderá ser reutilizada por outras solicitações, causando inconsistência no nível de isolamento.
SELECT connection_id(): Pode retornar IDs de thread diferentes para o que parece ser a mesma conexão, pois as conexões são reutilizadas entre solicitações.
SHOW PROCESSLIST e SQL Explorer: Os endereços IP e números de porta exibidos podem diferir do endereço IP e da porta reais da sua aplicação, já que as conexões são multiplexadas pelo PolarProxy.
Comando KILL: Retorna ERROR 1094 (HY000): Unknown thread id: xxx porque o ID da thread entre o cliente e o PolarProxy difere do ID da thread entre o PolarProxy e o banco de dados. O PolarProxy mescla os resultados de SHOW PROCESSLIST de todos os nós antes de retorná-los ao cliente.

Observações de uso

As configurações do pool de conexões entram em vigor apenas nas conexões criadas após a alteração. As conexões existentes não são afetadas. Para etapas de configuração, consulte Configure PolarProxy.
O pool de conexões não oferece suporte a permissões específicas de IP para uma conta. Se você conceder acesso a user@192.xx.xx.1 para database_a, mas não a user@192.xx.xx.2, poderá ocorrer um erro de permissão quando essa conexão for reutilizada. Evite configurar permissões diferentes para a mesma conta em endereços IP distintos quando o pool de conexões estiver ativado.