ApsaraDB RDS:Configure persistent connections

Switchover

Durante um switchover, o database proxy para ApsaraDB RDS for MySQL mantém uma conexão persistente em três etapas:

1. Início do switchover: Bloqueio de novas conexões e solicitações

   O proxy não consegue preservar transações. Por isso, trata as sessões de forma diferente com base em seus estados:

   • Sessões com transações ativas durante o período de bloqueio: o proxy encaminha as solicitações à instância primária de backend para execução.

   • Sessões que iniciam novas transações durante o período de bloqueio: o proxy bloqueia as solicitações e o cliente aguarda uma resposta do servidor.

   • Sessões com transações ainda ativas após o término do período de bloqueio: o proxy encerra a conexão e o banco de dados de backend reverte as transações não confirmadas.

   

2. Durante o switchover: Alternância das conexões existentes

   Durante o switchover, o estado das conexões existentes é modificado:

   • Conexões que não podem ser mantidas: o proxy encerra toda a conexão.

   • Conexões que podem ser mantidas: o proxy as alterna para a nova instância de banco de dados.

   • Limpeza do pool: o proxy remove as conexões com a instância primária original do pool de conexões.

   

3. Após o switchover: Restauração das conexões

   Para conexões mantidas com sucesso, o proxy estabelece conexões com a nova instância primária e restaura o estado da conexão.

   

Failover

Um failover é um evento não planejado no qual uma falha do sistema faz com que uma instância ApsaraDB RDS promova automaticamente uma instância secundária para se tornar a nova primária.

O proxy armazena em cache as instruções SQL em execução no banco de dados ou pendentes de encaminhamento. Quando ocorre uma falha no banco de dados, a conexão de backend entre o proxy e o banco de dados é interrompida. Após detectar o failover, o proxy não se desconecta imediatamente do cliente. Em vez disso, ele encaminha solicitações de leitura com falha para uma instância de banco de dados disponível e restaura o estado da conexão.

Pré-requisitos

Procedimento

1. Acesse a página ApsaraDB RDS Instances. Na barra de navegação superior, selecione a região onde a instância está localizada. Em seguida, localize a instância e clique em seu ID.

2. No painel de navegação à esquerda, clique em Database Proxy.

3. Na seção Basic Information, clique em Enable ao lado de Persistent Connection.

   Nota

   Se o texto 'persistent connection' não for exibido, significa que sua instância não atende aos requisitos para ativar conexões persistentes.

Pré-requisitos

• O database proxy está ativado.

• O recurso de conexão persistente está ativado para o database proxy.

Procedimento

1. Acesse a página ApsaraDB RDS Instances. Na barra de navegação superior, selecione a região onde a instância está localizada. Em seguida, localize a instância e clique em seu ID.

2. No painel de navegação à esquerda, clique em Database Proxy.

3. Configure uma política de acesso para o endpoint de database proxy de destino conforme os requisitos do seu negócio. Para obter mais informações, consulte Configurar uma política de acesso para um endpoint de database proxy. Defina Read/Write Attributes como Read/Write (Read/Write Splitting).

4. Solicite um endpoint interno ou público para o database proxy conforme os requisitos do seu negócio. Para obter mais informações, consulte Definir um endpoint de database proxy.

5. Na aplicação, use o endpoint interno ou público e o número da porta do database proxy para se conectar ao banco de dados.

6. Quando uma operação de O&M envolvendo um switchover ocorrer na instância de banco de dados, o database proxy manterá a conexão automaticamente. A conexão da aplicação com o proxy não será interrompida ao usar o endpoint de database proxy.

Limitações

Durante um switchover, o recurso de conexão persistente não consegue manter conexões nos seguintes cenários:

• Conexões com um conjunto de resultados incompleto, nas quais o servidor MySQL ainda não terminou de enviar todos os dados.

• Conexões com transações não confirmadas.

• Conexões que usaram uma instrução change user.

• Conexões que usaram uma instrução LOAD DATA.

• Conexões com tabelas temporárias.

• Conexões usadas para assinar logs binários por meio do endpoint de database proxy.

• Chamadas às funções FOUND_ROWS(), ROW_COUNT() e LAST_INSERT_ID() não são suportadas. Embora essas funções possam ser chamadas, a precisão dos resultados retornados não pode ser garantida. O MySQL não recomenda mais o uso de SELECT FOUND_ROWS(). Recomendamos substituir SELECT FOUND_ROWS() por SELECT COUNT(*) FROM tb1 nas consultas. Para obter mais informações, consulte FOUND_ROWS().

Observações de uso

• Como as conexões podem se reconectar, o ID de thread da conexão atual retornado pela consulta select connection_id() pode mudar.

• Devido ao restabelecimento das conexões, o endereço IP e a porta exibidos em show processlist ou no SQL Explorer podem não corresponder ao endereço IP e à porta reais do cliente.

• Se uma conexão possuir variáveis definidas pelo usuário, ela poderá ser mantida, mas as variáveis se tornarão inválidas.

sysbench --db-driver=mysql --mysql-host=127.X.X.1 --mysql-port=3306 --mysql-user=username --mysql-password='' --tables=100 --table-size=40000 --threads=128 --mysql-db=sbtest --report-interval=5  --time=600 oltp_read_write run