E novamente ERRO 1040 ...
O suporte técnico recebe muitas reclamações sobre esse erro notório: ERROR 1040: Too many connections - muitas conexões. O problema é óbvio: o aplicativo ou os usuários criam mais conexões do que o servidor permite, ou seja, o número atual de conexões excede o valor da variável max_connections .
A situação em si é um problema para os usuários finais, mas se você ainda não tiver acesso ao servidor para diagnosticar e corrigir a causa, tudo ficará muito ruim. Normalmente, você precisa concluir a instância e reiniciá-la para recuperar.
O usuário root também não pode se conectar! Porquê ?!
Em um ambiente configurado corretamente, um usuário com o privilégio SUPER poderá acessar a instância e diagnosticar a causa do erro 1040, devido à qual não há conexões suficientes. Isso é descrito no manual:
O mysqld permite max_connections + 1 conexões de clientes. Uma conexão adicional é reservada para contas com privilégios SUPER . Quando esses privilégios são concedidos a administradores e não a usuários comuns (que não precisam deles), um administrador que também tenha o privilégio PROCESS pode se conectar ao servidor e usar SHOW PROCESSLIST para diagnosticar problemas, mesmo se o número máximo de clientes sem privilégios estiver conectado.
Mas muitas pessoas dão privilégios SUPER aos seus usuários do aplicativo ou script - por causa dos requisitos do aplicativo (perigoso!) Ou pela falta de conhecimento das consequências, e então o usuário comum ocupa a conexão reservada e o usuário administrativo (geralmente root ) não pode se conectar.
Como garantir o acesso a uma instância
Você pode usar o conhecido hack com o GDB, que Aurimas recomendou há 100 anos para o erro 1040, mas agora existem soluções melhores. É verdade que eles devem primeiro ser ativados.
Com o Percona Server 5.5.29 e superior e o MySQL 8.0.14 e superior, você pode configurar outra porta com um número adicional de conexões. O aplicativo não usará essas interfaces. Eles são apenas para administradores de banco de dados e agentes de monitoramento e verificação de integridade (veja a nota abaixo).
Configurar o servidor Percona
A partir do Percona Server 5.5.29, você pode simplesmente adicionar extra_port ao my.cnf e, na próxima vez em que reiniciar, a porta estará disponível e esperará dados no mesmo bind_address ligação das conexões normais. Se você não configurar a variável extra_port , não haverá porta adicional por padrão.
Você também pode definir extra_max_connections para especificar o número de conexões que essa porta manipulará. O número padrão é 1.
Por exemplo, peguei todas as conexões com a porta de usuários regulares da instância em que eu já configurei extra_port e extra_max_connections no my.cnf :
resultado
A propósito, extra_port foi removido no Percona Server 8.0.14 e superior, porque admin_port com as mesmas funções é implementado na Comunidade MySQL. Portanto, edite my.cnf ao atualizar para o Percona Server 8.0.14 ou superior, se você já definiu extra_port.
Como eu disse, isso requer o MySQL 8.0.14, onde o WorkLog 12138 é usado .
Para ativar a interface de administração, você precisa definir admin_addres , que deve ser o único e único (sem curingas) endereço mapeado IPv4, IPv6, IPv4 ou nome do host no qual a interface de administração aguardará a transmissão dos dados. Se essa variável não estiver definida, a interface não estará ativada.
Você ainda pode definir a porta, mas isso não é necessário. Por padrão, essa é a porta 33062 . Se essa porta estiver livre, esse valor não precisará ser configurado. Se você configurar, coloque as duas variáveis na seção [mysqld] em my.cnf .
Por fim, você pode configurar o create_admin_listener_thread (desativado por padrão), que cria um encadeamento separado para manipular as conexões de entrada. Isso pode ser útil em algumas situações.
Outra diferença é que a documentação do Oracle diz que:
O número de conexões administrativas é ilimitado.
(E temos o valor padrão de 1). Não tenho certeza do que isso significa, mas eu teria cuidado para não estabelecer acidentalmente 1 milhão de conexões. Eles, é claro, não são limitados, mas ainda consomem recursos.
Use para monitoramento e verificações de saúde
Convenientemente, não apenas as pessoas podem usar uma interface ou porta adicional em uma emergência quando alcançamos max_connections . Um sistema de monitoramento de descoberta de proxy / balanceador de carga / serviço pode ser conectado a ele.
Os scripts de monitoramento poderão recuperar dados para diagramas, para que mais tarde você descubra de onde vêm tantas conexões. E os scripts de verificação de integridade relatam o estado de deterioração do servidor, e certos códigos podem indicar que há muitas conexões, mas o servidor está lidando (ou seja, ele pode descobrir isso sozinho e é melhor esperar um pouco mais até que ocorra uma falha).
Certifique-se de instalar apenas uma conexão por vez para monitoramento e verificações de integridade, para não entupir extra_max_connections no Percona Server e não criar um milhão de threads no MySQL. Ou seja, os scripts não devem ser conectados novamente se a solicitação ou conexão anterior ao banco de dados ainda estiver ativa.
Aqui está o mesmo exemplo, mas com o MySQL .
Para o Percona Server 8.0.14 e superior, o processo será o mesmo da Comunidade MySQL.
Ajuda! Eu preciso entrar, mas todas as portas estão ocupadas!
Se esse é o motivo pelo qual você está lendo esta postagem, use um hack louco com o GDB (sem ofensas, Aurimas, apenas parece arriscado :-D) ou encerre a instância. Felizmente, uma instância quase sempre pode ser terminada ordenadamente com SIGTERM (-15) em vez de SIGKILL (-9). Portanto, o servidor fará uma parada limpa e os threads terão a chance de desligar normalmente. Basta seguir as instruções:
1) Obtenha o PID:
marcos.albe in ~/ pgrep -x mysqld; 650
2) Envie o SIGTERM para este PID:
marcos.albe in ~/ kill -15 650;
3) Verifique no log de erros como o desligamento é realizado. Será algo parecido com isto:
2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully 2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads 2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients
Isso marca o início do processo de conclusão. A instância será concluída quando você vir uma linha semelhante:
2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete