Solucionar erro 'Too many connections' no MySQL 8.0 Debian 12

12 min de leitura  ·  Guia técnico

O erro "Too many connections" no MySQL 8.0 ocorre quando o número de sessões simultâneas atinge o valor definido em max_connections (padrão 151). A correção rápida é aumentar esse limite via SET GLOBAL e ajustar wait_timeout para liberar conexões ociosas. Veja abaixo como diagnosticar a causa raiz e aplicar a solução definitiva no Debian 12.

Pré-requisitos

• Servidor com Debian 12 (Bookworm) e MySQL Server 8.0 instalado via APT.
• Acesso root via SSH ou usuário com privilégios sudo.
• Credenciais do usuário root do MySQL ou outro usuário com privilégio SUPER / SYSTEM_VARIABLES_ADMIN.
• Pelo menos 2 GB de RAM disponíveis — cada conexão consome memória adicional.
• Editor de texto (nano ou vim) e conhecimento básico de systemctl.

Diagnosticando o erro "Too many connections" no MySQL 8.0

Antes de alterar qualquer parâmetro, é essencial confirmar o estado atual do servidor. O erro "Too many connections" no MySQL 8.0 geralmente vem acompanhado da mensagem ERROR 1040 (HY000) retornada ao cliente ou registrada no log de erro em /var/log/mysql/error.log. No Debian 12, o serviço se chama mysql.service e as configurações ficam em /etc/mysql/mysql.conf.d/mysqld.cnf.

Conecte-se ao servidor e verifique os valores atuais das variáveis relevantes:

sudo mysql -u root -p

Dentro do prompt MySQL, execute:

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';
SHOW STATUS LIKE 'Connection_errors_max_connections';

Output esperado (exemplo):

+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 148   |
+-------------------+-------+

+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 151   |
+----------------------+-------+

Se Max_used_connections estiver igual a max_connections e Connection_errors_max_connections for maior que zero, confirma-se o esgotamento do pool. Anote esses números: eles serão a base do dimensionamento.

Analisando processos ativos e identificando conexões zumbis

Antes de simplesmente elevar o teto, investigue quem está consumindo as sessões. Sessões no estado Sleep por longos períodos são o sintoma clássico de aplicações que abrem conexões e não as devolvem ao pool. No MySQL 8.0, utilize SHOW PROCESSLIST ou consulte diretamente a performance_schema:

SHOW FULL PROCESSLIST;

Para uma visão agregada por usuário e estado, rode:

SELECT user, host, db, command, COUNT(*) AS total
FROM information_schema.processlist
GROUP BY user, host, db, command
ORDER BY total DESC;

Output esperado:

+---------+----------------+----------+---------+-------+
| user    | host           | db       | command | total |
+---------+----------------+----------+---------+-------+
| wp_user | 10.0.0.12:5412 | wordpress| Sleep   |   92  |
| wp_user | 10.0.0.12:5413 | wordpress| Query   |    4  |
| root    | localhost      | NULL     | Query   |    1  |
+---------+----------------+----------+---------+-------+

Noventa e duas conexões em Sleep indicam que a aplicação (neste caso, WordPress) não está reutilizando conexões corretamente. Matar um processo específico é feito com KILL <id>, mas trata-se de paliativo. A solução estrutural é ajustar wait_timeout ou implementar pool no lado do cliente.

Ajustando max_connections no MySQL 8.0 em tempo real

No Debian 12, você pode elevar o limite imediatamente sem reiniciar o serviço — útil durante picos de tráfego. A alteração dinâmica vale até o próximo restart:

sudo mysql -u root -p -e "SET GLOBAL max_connections = 500;"

Confirme com:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"

Output esperado:

+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 500   |
+-----------------+-------+

Atenção: elevar max_connections sem considerar a RAM disponível pode levar o servidor a swap ou a invocar o OOM Killer. Cada sessão reserva buffers privados. Calcule aproximadamente max_connections × (sort_buffer_size + join_buffer_size + read_buffer_size + thread_stack) antes de aplicar valores altos.

Tornando a alteração de max_connections permanente

Para persistir após reboot, edite o arquivo de configuração principal no Debian 12:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Na seção [mysqld], adicione ou atualize:

[mysqld]
max_connections = 500
max_connect_errors = 1000
wait_timeout = 120
interactive_timeout = 300

Salve, saia e reinicie o serviço:

sudo systemctl restart mysql
sudo systemctl status mysql

Output esperado:

● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled)
     Active: active (running) since ...

Reduzindo wait_timeout para liberar conexões ociosas

A estratégia mais eficaz em servidores web é reduzir o tempo que uma conexão Sleep permanece viva. O valor padrão do MySQL 8.0 é 28800 segundos (8 horas) — absurdo para APIs e CMS. Ajustar para 60 a 120 segundos costuma resolver grande parte dos incidentes sem mexer em max_connections.

Aplicação dinâmica:

SET GLOBAL wait_timeout = 120;
SET GLOBAL interactive_timeout = 300;

Para persistência, mantenha as linhas no mysqld.cnf conforme mostrado acima. Reinicie o serviço se desejar garantir efeito em todas as sessões novas. Conexões já abertas herdam o timeout do momento em que foram criadas — apenas novas conexões respeitam o valor recém-aplicado.

Se você gerencia bancos via painel, veja também o artigo Conectando remotamente ao MySQL - cPanel para garantir que clientes externos não mantenham sessões penduradas por configuração errada no gerenciador.

Dimensionando corretamente o limite de conexões simultâneas

O dimensionamento correto do pool de sessões depende de três fatores: RAM disponível, perfil de uso da aplicação e tamanho dos buffers. Uma fórmula conservadora para servidores dedicados ao MySQL:

• RAM reservada ao InnoDB buffer pool: 50% a 70% da memória total.
• RAM por conexão: estime 4 MB a 8 MB em configurações padrão.
• Fórmula prática: max_connections = (RAM_total - InnoDB_buffer_pool - 1GB) / 8MB.

Em um VPS Debian 12 com 8 GB de RAM, com innodb_buffer_pool_size=4G, reserve ~1 GB para o sistema e divida os 3 GB restantes por 8 MB — resultando em aproximadamente 375 conexões com folga. Para confirmar o limite do sistema operacional, verifique também o ulimit do usuário mysql:

sudo cat /proc/$(pgrep -n mysqld)/limits | grep "open files"

O MySQL 8.0 no Debian 12 normalmente já vem configurado com LimitNOFILE=10000 via systemd. Se precisar aumentar, edite /etc/systemd/system/mysql.service.d/override.conf:

[Service]
LimitNOFILE=20000

Depois execute sudo systemctl daemon-reload && sudo systemctl restart mysql.

Problemas comuns e como resolver

Sintoma: erro retorna mesmo após aumentar max_connections

Causa: vazamento de conexões na aplicação — sessões são abertas mas nunca fechadas, geralmente por falta de try/finally no código ou ausência de pool.
Solução: rode SHOW PROCESSLIST durante o pico e verifique se há centenas de conexões em Sleep do mesmo usuário. Implemente connection pooling (PDO persistent, HikariCP, SQLAlchemy pool) e reduza wait_timeout para 60 segundos como rede de segurança.

Sintoma: MySQL reinicia sozinho após elevar max_connections

Causa: esgotamento de memória. O OOM Killer do kernel encerra o processo mysqld quando a soma de buffers por conexão excede a RAM disponível.
Solução: verifique dmesg | grep -i "out of memory" e journalctl -u mysql --since "1 hour ago". Reduza sort_buffer_size, join_buffer_size e read_buffer_size para valores moderados (256K–2M) e reavalie o total de conexões.

Sintoma: administradores não conseguem logar quando o limite é atingido

Causa: todas as 151 slots padrão estão ocupadas por aplicações, sem reserva para manutenção.
Solução: use a variável mysqlx_max_connections ou configure uma conexão administrativa via socket. O MySQL 8.0 reserva automaticamente uma conexão extra para usuários com privilégio CONNECTION_ADMIN — garanta que seu usuário root tenha esse grant: GRANT CONNECTION_ADMIN ON *.* TO 'root'@'localhost';.

Sintoma: Connection_errors_max_connections cresce continuamente

Causa: picos legítimos de tráfego ou ataques que esgotam o pool.
Solução: monitore com watch -n 5 "mysql -e 'SHOW STATUS LIKE \"Threads_connected\"'". Considere instalar otimizações gerais no Linux e usar ProxySQL como camada de multiplexação de conexões, reduzindo a pressão direta no MySQL.

Perguntas frequentes sobre erro "Too many connections" no MySQL

O que significa o erro 'Too many connections' no MySQL?

O erro indica que o servidor MySQL atingiu o limite configurado na variável max_connections e não consegue aceitar novas sessões. Ele acontece quando aplicações abrem conexões mais rápido do que as fecham, quando há vazamento de conexões ou quando o valor padrão de 151 é baixo para a carga real do ambiente.

Como aumentar o max_connections no MySQL 8.0 sem reiniciar o serviço?

Conecte-se como root via mysql client e execute SET GLOBAL max_connections = 500. A alteração passa a valer imediatamente para novas conexões, mas é perdida no próximo restart. Para torná-la permanente, adicione max_connections=500 na seção [mysqld] do arquivo /etc/mysql/mysql.conf.d/mysqld.cnf.

Aumentar max_connections resolve o problema definitivamente?

Nem sempre. Se a causa raiz for vazamento de conexões na aplicação ou ausência de pool, aumentar o limite apenas adia o problema e consome mais RAM. O ideal é identificar processos ociosos com SHOW PROCESSLIST, ajustar wait_timeout e implementar pool de conexões no lado da aplicação.

Quanto de RAM cada conexão MySQL consome?

Cada conexão reserva buffers próprios (sort_buffer_size, join_buffer_size, read_buffer_size) que somam entre 2 MB e 12 MB por sessão, dependendo da configuração. Em um servidor com max_connections=1000 e buffers agressivos, o consumo teórico pode ultrapassar 10 GB apenas com conexões abertas, sem contar o InnoDB buffer pool.

Qual a diferença entre wait_timeout e interactive_timeout?

O wait_timeout controla o tempo ocioso de conexões não-interativas (aplicações, APIs, scripts), enquanto interactive_timeout afeta apenas sessões do cliente mysql no terminal. Reduzir wait_timeout para 60-120 segundos é a forma mais eficaz de liberar conexões zumbis em servidores web.

Conclusão

• Diagnostique sempre antes de elevar limites: inspecione SHOW PROCESSLIST e Connection_errors_max_connections para identificar se o problema é carga real ou vazamento de conexões.
• Ajuste wait_timeout para 60–120 segundos no mysqld.cnf — é a mudança de maior impacto imediato em ambientes web com MySQL 8.0 no Debian 12.
• Dimensione max_connections com base na RAM disponível e nos buffers por sessão, e considere ProxySQL ou connection pooling na aplicação antes de escalar verticalmente o servidor.

Leia também

• Solucionar problemas de permissão no MySQL: exemplos reais no Ubuntu 22.04
• Como otimizar o MySQL para alta performance no VPS Linux (com exemplos reais)
• Manual do InnoDB: tuning de buffer pool e I/O no MySQL 8.0

Precisa de ajuda com MySQL em servidores de alta demanda?

Se seu banco de dados sofre com picos de conexão e você precisa de infraestrutura com RAM dedicada, IOPS consistente e suporte técnico em português, um VPS dimensionado corretamente faz toda diferença na estabilidade do MySQL 8.0.

Conheça os planos de VPS Linux da AviraHost