Configure connection pooling for ApsaraDB RDS for MySQL - ApsaraDB RDS: Central de Documentação do Alibaba Cloud

Escolha um tipo de pool de conexões

O proxy de banco de dados do ApsaraDB RDS for MySQL oferece pool de conexões no nível de transação e no nível de sessão. Decida se deseja usar o pool de conexões e selecione um tipo com base no seu caso de uso.

Tipo de pool de conexões	Casos de uso
Pool de conexões no nível de transação (recomendado)	Cenários com conexões de curta duração, criação frequente de conexões e um número de conexões que se aproxima do limite do banco de dados MySQL. As limitações do pool de conexões no nível de transação não afetam a sua aplicação. limitações
Pool de conexões no nível de sessão	Cenários com conexões de curta duração e criação frequente de conexões, mas em que a aplicação é afetada pelas limitações do pool de conexões no nível de transação.
Não usar pool de conexões	Cenários com conexões persistentes, um número pequeno de conexões ou um pool de conexões no lado da aplicação, como Druid, DBCP, C3P0 ou HikariCP.

Tipos de pool de conexões

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

Casos de uso

A sua aplicação usa predominantemente conexões de curta duração.
A aplicação cria conexões com frequência.
O número de conexões é alto e se aproxima do limite de conexões do banco de dados MySQL.

Benefícios

Reduz a frequência de estabelecimento de conexões entre a aplicação e o banco de dados, diminuindo a sobrecarga na thread principal do MySQL.
Reduz o número total de conexões com o banco de dados.

Como funciona

Após ativar o pool de conexões no nível de transação, quando um cliente inicia uma solicitação de sessão, o proxy de banco de dados estabelece uma conexão de frontend com o cliente, mas não cria imediatamente uma conexão de backend com o banco de dados. Ao receber uma solicitação para processamento, o proxy verifica o pool de conexões no nível de transação em busca de uma conexão de backend disponível.

Nota

Uma conexão de backend está disponível se os parâmetros user e dbname e alguns valores de variáveis do sistema corresponderem aos da solicitação.

Se houver uma conexão disponível, o proxy a reutiliza. Após a conclusão da transação, o proxy devolve a conexão ao pool de conexões no nível de transação.
Se não houver nenhuma conexão disponível, o proxy cria uma nova conexão de backend com o banco de dados.

Várias sessões podem compartilhar uma única conexão de backend. Sessões com transações ativas ocupam uma conexão de backend, enquanto sessões com transações inativas não a ocupam, conforme mostra a figura a seguir.

Ao permitir que uma única conexão de backend processe solicitações de transação de várias sessões ao longo do tempo, este modelo oferece as seguintes vantagens:

Frequência de conexão reduzida: o backend mantém conexões persistentes com o banco de dados, reduzindo a necessidade de estabelecer novas conexões com frequência e a carga na thread principal do banco de dados.
Menor número total de conexões: várias sessões compartilham a mesma conexão de backend, evitando que conexões ociosas consumam recursos e reduzindo o número total de conexões com o banco de dados.

Nota

O próprio proxy de banco de dados não impõe um limite máximo de conexões; as especificações do banco de dados de backend determinam esse limite.

Limitações

A execução das operações a seguir bloqueia a conexão até o seu fechamento. O proxy não devolve uma conexão bloqueada ao pool de conexões para reutilização.
- Execute uma instrução ou comando PREPARE.
- Crie uma tabela temporária.
- Modifique variáveis de usuário.
- Processe pacotes grandes (por exemplo, 16 MB ou mais).
- Use LOCK TABLE.
- Execute consultas com várias instruções.
- Chame um stored procedure.
As funções FOUND_ROWS, ROW_COUNT e LAST_INSERT_ID não têm suporte. Você pode chamar essas funções, mas não há garantia de que os resultados estejam corretos.
- Se a versão do proxy for 1.13.11 ou posterior, você pode usar o comando SELECT FOUND_ROWS() imediatamente após uma instrução SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT *. No entanto, o MySQL não recomenda mais esse uso. Recomendamos substituir SELECT FOUND_ROWS() por SELECT COUNT(*) FROM tb1. Para mais informações, consulte FOUND_ROWS().
- Se a versão do proxy for 1.13.11 ou posterior, você pode usar a instrução SELECT LAST_INSERT_ID() imediatamente após uma instrução INSERT para garantir um resultado de consulta correto.

Notas de uso

Para conexões em que wait_timeout está definido, a configuração de wait_timeout pode não ter efeito no lado do cliente, pois cada solicitação obtém uma conexão do pool. Quando o período de wait_timeout expira, o sistema desconecta apenas a conexão de backend no pool, sem desconectar a conexão do cliente.
Exceto pelas variáveis sql_mode, character_set_server, collation_server e time_zone, se a sua aplicação depender de outras variáveis de sistema no nível de sessão, o cliente deve executar explicitamente uma instrução SET após estabelecer uma conexão. Caso contrário, o pool de conexões pode reutilizar uma conexão com variáveis de sistema modificadas.
Como o pool pode reutilizar conexões, execute select connection_id() para consultar o ID da thread da conexão atual.
Devido à reutilização de conexões, o endereço IP e a porta exibidos por show processlist ou SQL Explorer and Audit podem não corresponder ao endereço IP e à porta reais do cliente.
O proxy de banco de dados mescla e retorna os resultados de show processlist de todos os nós. Não é possível mapear os IDs de thread das conexões de frontend e backend. Isso pode fazer com que o comando KILL reporte um erro mesmo após a execução bem-sucedida do comando.

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

Casos de uso

A sua aplicação usa predominantemente conexões de curta duração.
A aplicação cria conexões com frequência.

Benefícios

Reduz a frequência de estabelecimento de conexões entre a aplicação e o banco de dados, diminuindo a sobrecarga na thread principal do MySQL.

Como funciona

Conexões de frontend e backend

Quando um cliente, como uma aplicação, estabelece uma conexão com um banco de dados, o proxy de banco de dados atua como um intermediário. Ele divide a conexão em uma conexão de frontend entre o cliente e o proxy de banco de dados, e uma conexão de backend entre o proxy de banco de dados e o banco de dados, conforme mostra a figura a seguir.

Processo de conexão quando o pool de conexões está desativado

Se o pool de conexões estiver desativado, o proxy cria uma nova conexão de frontend e backend para cada sessão.

Como funciona o pool de conexões no nível de sessão

Ao estabelecer uma sessão, o pool de conexões no nível de sessão cria primeiro uma conexão de frontend. Em seguida, verifica o pool em busca de uma conexão de backend disponível.

Nota

Uma conexão está disponível se os parâmetros user, clientip e dbname corresponderem aos da solicitação.

Se houver uma conexão disponível, o proxy a reutiliza.
Se não houver nenhuma conexão disponível, o proxy estabelece uma nova conexão de backend com o banco de dados.

Quando uma sessão termina, o proxy desconecta a conexão de frontend e devolve a conexão de backend ao pool. Isso permite que uma nova sessão reutilize a conexão de backend, reduzindo a sobrecarga na thread principal do banco de dados.

Com o pool de conexões no nível de sessão, uma sessão ocupa uma conexão de backend até o seu término. Somente então o sistema libera a conexão de backend para o pool, conforme mostra a figura a seguir.

Limitações

Nenhuma.

Notas de uso

Antes do término de uma sessão, outras sessões não podem usar sua conexão de backend, mesmo que esteja ociosa e sem transações para processar. Portanto, o pool de conexões no nível de sessão não reduz o número total de conexões do banco de dados.

Configure o pool de conexões

Pré-requisitos

O proxy de banco de dados está ativado.

Notas de uso

O recurso de pool de conexões não oferece suporte à atribuição de permissões diferentes à mesma conta com base em endereços IP diferentes. Se você configurar permissões de banco de dados ou tabelas diferentes para a mesma conta em endereços IP diferentes (por exemplo, user@192.xx.xx.1 tem permissões para database_a, mas user@192.xx.xx.2 não tem), a ativação do pool de conexões pode causar erros de permissão ao reutilizar conexões.
Se a sua aplicação já usa um pool de conexões no lado do cliente, você não precisa ativar o pool de conexões do proxy de banco de dados.
O pool de conexões não pode corrigir um acúmulo de conexões causado por inúmeras consultas SQL lentas. Recomendamos otimizar suas consultas SQL ou solucionar a causa da lentidão na instância MySQL.
Se a versão do proxy for anterior a 2.9.1, você não pode configurar o pool de conexões para endpoints de proxy somente leitura. Se a versão do proxy for 2.9.1 ou posterior, você pode configurar o pool de conexões para endpoints de proxy de leitura/gravação e somente leitura.

Procedimento

Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS reside. Em seguida, localize a instância RDS e clique no ID da instância.
No painel de navegação à esquerda, clique em Database Proxy.
Na seção Connection Information, ative o pool de conexões usando um dos métodos a seguir:
Nota
- O pool de conexões vem desativado por padrão.
- Após alterar o tipo de pool de conexões, a alteração se aplica apenas a novas conexões.
- Método 1: Passe o mouse sobre o ícone à direita do ID do endpoint de proxy. Na caixa de diálogo exibida, clique em Enable Transaction-level Connection Pooling ou Enable Session-level Connection Pooling e, em seguida, clique em OK na caixa de diálogo de confirmação.
- Método 2: Na coluna Actions do endpoint de proxy de destino, clique em Modify Configuration. Na caixa de diálogo exibida, selecione o tipo de pool de conexões desejado ao lado de Connection Pooling para ativá-lo.
  
  Nota
  Se um tipo de pool de conexões já estiver ativado, selecione um tipo diferente para modificá-lo.
  
  Nesta caixa de diálogo, você também pode configurar o Read/write attribute (opções: Read/write (read/write splitting) ou Read-only), Latency threshold (intervalo: 0 a 3.600 segundos), Transaction splitting (ativado ou desativado) e Read weight allocation (opções: System-assigned ou pesos personalizados).

Referência de API

API

Descrição

DescribeDBProxy

Consulta os detalhes do proxy de banco de dados de uma instância RDS.

DescribeDBProxyEndpoint

Consulta informações sobre os endpoints de proxy de uma instância RDS.

ModifyDBProxyEndpoint

Modifica a configuração de um endpoint de proxy de uma instância RDS.

Conceitos principais

conexão de curta duração: conexão mantida apenas por um curto período. Por exemplo, uma aplicação PHP fecha uma conexão após executar uma consulta simples. Essa abordagem evita ocupar uma conexão por longos períodos, mas exige o estabelecimento de uma nova conexão para cada solicitação, o que aumenta a sobrecarga na thread principal do banco de dados.
conexão persistente: conexão mantida por um longo período. Por exemplo, um servidor web ou um servidor de aplicação abre várias conexões com um servidor MySQL e as mantém abertas até que o cliente pare. Isso reduz a sobrecarga da thread principal ao minimizar novas solicitações de conexão, mas ocupa um canal de conexão por um tempo prolongado.

Perguntas frequentes

P: Com qual número de conexões devo ativar o pool de conexões?

R: Recomendamos ativar o pool de conexões no nível de transação quando o número de conexões se aproximar do limite do MySQL.

P: Por quanto tempo o pool de conexões mantém uma conexão?

R: 10 segundos.

P: O uso do pool de conexões afeta o desempenho da instância?

R: Em cenários com conexões de curta duração, ativar o pool de conexões pode melhorar o desempenho da instância em aproximadamente 10%.

P: Qual é a diferença funcional entre o pool de conexões no nível de transação e no nível de sessão?

R: O pool de conexões no nível de transação reduz tanto a sobrecarga da thread principal quanto o número total de conexões. O pool de conexões no nível de sessão reduz apenas a sobrecarga da thread principal.

P: Como o pool de conexões no nível de transação e no nível de sessão diferem em seu funcionamento?

R:

Tipo de pool de conexões

Compartilhamento de sessão

Momento de obtenção

Momento de devolução

Mapeamento de conexão

Nível de transação

Sim

Quando uma transação é processada

Após uma transação ser processada (a sessão ainda pode estar ativa)

N:1

Nível de sessão

Não

Quando uma sessão é estabelecida

Quando a sessão termina

N:N

P: A conexão do proxy de banco de dados foi encerrada. Isso ocorre porque tanto a aplicação quanto o proxy de banco de dados estão usando pool de conexões?

R: Uma conexão pode ser encerrada por vários motivos, não necessariamente porque tanto a aplicação quanto o proxy usam pool de conexões. A causa raiz depende da sua carga de trabalho e configuração específicas.