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 pools 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 o tipo adequado 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 quantidade de conexões próxima ao limite do banco de dados MySQL. Seu negócio não é afetado pelas limitações do pool de conexões no nível de transação.
Pool de conexões no nível de sessão	Indicado para 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 no nível de transação.
Não usar pool de conexões	Recomendado quando há conexões persistentes, poucas conexões ou quando já existe 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

Sua aplicação utiliza predominantemente conexões de curta duração.
As conexões são criadas com frequência.
O volume de conexões é elevado e se aproxima do limite suportado pelo banco de dados MySQL.

Benefícios

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

Funcionamento

Ao 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 frontend com o cliente, mas não cria imediatamente uma conexão backend com o banco de dados. Quando uma solicitação precisa ser processada, o proxy verifica se existe uma conexão backend disponível no pool de conexões no nível de transação.

Nota

Uma conexão backend é considerada disponível se seus parâmetros user e dbname e alguns valores de variáveis de sistema forem consistentes com a solicitação.

Caso exista 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 backend com o banco de dados.

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

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

Menor frequência de conexões: O backend mantém conexões persistentes com o banco de dados, reduzindo a necessidade de estabelecer novas conexões frequentemente e diminuindo a carga na thread principal do banco de dados.
Redução no total de conexões: Várias sessões compartilham a mesma conexão 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; esse limite é determinado pelas especificações do banco de dados backend.

Limitações

A execução das operações a seguir bloqueia a conexão até que ela seja fechada. Uma conexão bloqueada não retorna ao pool de conexões para reutilização.
- Executar uma instrução ou comando PREPARE.
- Criar uma tabela temporária.
- Modificar variáveis de usuário.
- Processar pacotes grandes (por exemplo, 16 MB ou mais).
- Usar LOCK TABLE.
- Executar consultas com múltiplas instruções.
- Chamar um procedimento armazenado.
As funções FOUND_ROWS, ROW_COUNT e LAST_INSERT_ID não são suportadas. É possível 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. Substitua SELECT FOUND_ROWS() por SELECT COUNT(*) FROM tb1. Para mais informações, consulte FOUND_ROWS().
- Caso a versão do proxy seja 1.13.11 ou superior, utilize a instrução SELECT LAST_INSERT_ID() logo após uma instrução INSERT para garantir um resultado de consulta correto.

Observações 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, apenas a conexão backend no pool é desconectada, o que não causa a desconexão da conexão do cliente.
Exceto pelas variáveis sql_mode, character_set_server, collation_server e time_zone, se 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 a conexão. Caso contrário, o pool de conexões poderá reutilizar uma conexão cujas variáveis de sistema foram modificadas.
Como as conexões podem ser reutilizadas, execute select connection_id() para consultar o ID da thread da conexão atual.
Devido à possível reutilização de conexões, o endereço IP e a porta exibidos por show processlist ou pelo SQL Explorer and Audit podem não corresponder ao endereço IP e à porta reais do cliente.
O proxy de banco de dados consolida os resultados de show processlist de todos os nós e os retorna. Os IDs de thread das conexões frontend e backend não podem ser mapeados. Isso pode fazer com que o comando KILL reporte um erro mesmo tendo sido executado com sucesso.

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

Casos de uso

Sua aplicação usa predominantemente conexões de curta duração.
A criação de conexões ocorre frequentemente.

Benefícios

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

Funcionamento

Conexões frontend e backend

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

Processo de conexão com o pool desativado

Se o pool de conexões estiver desativado, o proxy cria novas conexões 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 frontend. Em seguida, verifica se há uma conexão backend disponível no pool.

Nota

Uma conexão é considerada disponível se seus parâmetros user, clientip e dbname corresponderem aos da solicitação.

Se existir uma conexão disponível, ela será reutilizada.
Caso não haja conexão disponível, uma nova conexão backend é estabelecida com o banco de dados.

Quando uma sessão termina, o proxy desconecta a conexão frontend e devolve a conexão backend ao pool. Isso permite que a conexão backend seja reutilizada por uma nova sessão, 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 backend até que a sessão termine. Somente então a conexão backend é liberada para o pool, conforme ilustrado na figura a seguir.

Limitações

Nenhuma.

Observações de uso

Antes que uma sessão termine, sua conexão backend não pode ser usada por outras sessões, 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 com o banco de dados.

Configure pool de conexões

Pré-requisitos

O proxy de banco de dados está ativado.

Observações de uso

O recurso de pool de conexões não suporta a atribuição de permissões diferentes à mesma conta com base em endereços IP distintos. Se você configurar permissões diferentes de banco de dados ou tabelas para a mesma conta em IPs diferentes (por exemplo, user@192.xx.xx.1 tem permissões para database_a, mas user@192.xx.xx.2 não), ativar o pool de conexões pode causar erros de permissão quando as conexões forem reutilizadas.
Caso sua aplicação já utilize um pool de conexões no lado do cliente, não é necessário ativar o pool de conexões do proxy de banco de dados.
O pool de conexões não resolve acúmulos de conexões causados por numerosas 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, não é possível configurar o pool de conexões para endpoints de proxy somente leitura. Para versões 2.9.1 ou posteriores, é possível configurar o pool tanto para endpoints de proxy de leitura/gravação quanto para somente leitura.

Procedimento

Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS está localizada. Em seguida, localize a instância RDS e clique em 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 mudança 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 desejado, 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, também é possível 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 para uma instância RDS.

Conceitos principais

Conexão de curta duração: Conexão mantida apenas por um breve período. Por exemplo, uma aplicação PHP fecha a 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, aumentando 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 de aplicações 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 solicitações de novas conexões, 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 a contagem de conexões se aproximar do limite do MySQL.

P: Por quanto tempo uma conexão é mantida no pool de conexões?

R: 10 segundos.

P: O uso de 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 no nível de transação reduz tanto a sobrecarga da thread principal quanto o número total de conexões. O pool 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ões
Nível de transação	Sim	Quando uma transação é processada	Após o processamento da transação (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 desconectada. Isso ocorreu porque tanto a aplicação quanto o proxy estão usando pool de conexões?

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