As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Como gerenciar conexões
À medida que a demanda por sua aplicação cresce, o tráfego de front-end aumenta. Em um cenário típico, você configura o escalonamento automático na camada de aplicação para lidar com essa explosão de tráfego de entrada. Como resultado, a camada de aplicação começa a ser escalada automaticamente, e mais servidores de aplicações (instâncias) são adicionados para atender ao aumento do tráfego. Como todos os servidores de aplicações têm configurações pré-definidas do pool de conexões de banco de dados, o número de conexões de entrada com o banco de dados cresce proporcionalmente às instâncias recém-implantadas.
Por exemplo, 20 servidores de aplicações configurados com 200 conexões de banco de dados cada abririam um total de 4.000 conexões de banco de dados. Se o pool de aplicações for escalado para até 200 instâncias (por exemplo, durante os horários de pico), a contagem total de conexões chegará a 40.000. Em uma workload típica, a maioria dessas conexões provavelmente está ociosa. Mas o aumento nas conexões pode limitar a capacidade de escalabilidade do seu banco de dados do Amazon Aurora Edição Compatível com MySQL. Isso ocorre porque até mesmo conexões ociosas consomem memória e outros recursos do servidor, como descritores de arquivos. O Aurora Edição Compatível com MySQL normalmente usa menos memória do que o MySQL Community Edition para manter o mesmo número de conexões. No entanto, o uso de memória para conexões ociosas ainda não é zero.
Variáveis de configuração
É possível controlar o número de conexões de entrada permitidas em seu banco de dados com duas variáveis principais de configuração do servidor: max_connections e max_connect_errors.
Variável de configuração max_connections
A variável de configuração max_connections limita o número de conexões de banco de dados para cada instância do MySQL. A prática recomendada é configurá-la um pouco acima do número máximo de conexões que você espera abrir em cada instância de banco de dados.
Se você também habilitou o performance_schema, tenha muito cuidado com a configuração max_connections. As estruturas de memória do Performance Schema são dimensionadas automaticamente com base nas variáveis de configuração do servidor, incluindo max_connections. Quanto maior a configuração da variável, mais memória o Performance Schema usa. Em casos extremos, isso pode causar out-of-memory problemas em tipos de instâncias menores. Observe que ativar o Performance Insights habilitará automaticamente o Performance Schema.
Variável de configuração max_connect_errors
A variável de configuração max_connect_errors determina quantas solicitações sucessivas de conexão interrompida são permitidas de um determinado host cliente. Se o host cliente exceder o número especificado de tentativas sucessivas de conexão malsucedidas, o servidor o bloqueará. Tentativas adicionais de conexão desse cliente gerarão um erro.
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
Se você tiver erros de “o host está bloqueado”, evite aumentar o valor da max_connect_errors variável. Em vez disso, investigue os contadores de diagnóstico do servidor na variável de status aborted_connects e a tabela host_cache. Use as informações coletadas para identificar e corrigir clientes com problemas de conexão. Além disso, observe que esse parâmetro não terá efeito se skip_name_resolve estiver definido como 1 (padrão).
Consulte o Manual de referência do MySQL para obter detalhes sobre:
Implementar um pool de conexões
Um evento de escalabilidade pode adicionar mais servidores de aplicações, o que, por sua vez, pode fazer com que o servidor de banco de dados exceda o número de conexões ativas totalmente carregadas. A adição de um pool de conexões ou camada de proxy entre os servidores de aplicações e o banco de dados age como um funil, reduzindo o número total de conexões no banco de dados. O objetivo principal de um proxy é a reutilização de conexões de banco de dados por meio de multiplexação.
De um lado, o proxy se conecta ao banco de dados com um número controlado de conexões. Por outro, o proxy aceita conexões de aplicações. Ele também fornece recursos adicionais, como cache de consultas, buffer de conexão, reescrita e roteamento de consultas e balanceamento de carga. A camada do pool de conexões precisa ser configurada para manter o número máximo de conexões com o banco de dados abaixo do número totalmente carregado. O Amazon RDS Proxy
Também é possível explorar os seguintes proxies de terceiros que podem ser usados com o Aurora Edição Compatível com MySQL:
Evite tempestades de conexão
Considere como seu pool de conexões se comporta no caso de um banco de dados sobrecarregado ou uma réplica ficar muito para trás em relação ao nó primário. Ao configurar seu servidor proxy ou pools de conexão, certifique-se de não redefinir todo o pool de conexões com base em respostas lentas do banco de dados (causadas por problemas subjacentes de hardware ou armazenamento ou restrições de recursos de banco de dados).
O início repentino de centenas de conexões gera uma tempestade de conexões porque um grande número de solicitações de novas conexões com o banco de dados são todas iniciadas ao mesmo tempo. A tempestade consome muitos recursos. Criar uma nova conexão de banco de dados no MySQL é uma operação cara porque o back-end troca vários pacotes de rede para o handshake inicial, gera um novo processo, aloca memória, manipula a autenticação e assim por diante. Se um grande número de solicitações for recebido em um curto período de tempo, o banco de dados poderá aparentar não estar respondendo.
O MySQL tem um mecanismo de proteção contra esse aumento nas solicitações de conexão. A variável back_log pode ser definida como o número de solicitações que podem ser empilhadas durante um curto período de tempo antes que o MySQL pare momentaneamente de responder a novas solicitações. O valor é imposto por um thread de manipulações de conexão que, por si só, pode ser sobrecarregado por uma tempestade de conexões. Para obter mais informações, consulte o Manual de referência do MySQL
Se sua conexão estiver configurada para ser redefinida quando o banco de dados estiver lento, você iniciará o ciclo repetidamente. Da mesma forma, se você antecipar um aumento repentino no tráfego do banco de dados em determinados momentos do dia (por exemplo, quando o mercado de ações abre), pré-aqueça seu pool de conexões para que você não tente abrir muitas conexões ao mesmo tempo em que uma carga de tráfego elevada está começando.
