|
Recentemente, um servidor MySQL foi encontrado devido a alguns fatores especiais“ERRO 1129 (00000): O host 'xxx' está bloqueado devido a muitos erros de conexão. Desbloqueie com 'mysqladmin flush-hosts'”Depois que o problema foi resolvido, no processo de aprender mais sobre o max_connect_errors de parâmetros, algumas descrições contraditórias de diferentes dados de rede me confundiram um pouco (sobre esse erro, a razão essencial é que o mesmo IP gerou muitas conexões de banco de dados interrompidas (excedendo o valor máximo de max_connect_errors) em um curto período de tempo, e a seguir é um processo de explorar meus problemas, analisar problemas e esclarecer dúvidas. Primeiro, pesquisei algumas informações na Internet, muitas das quais prometem introduzir que, se o número de tentativas de senha ultrapassar max_connect_errors variáveis, o MySQL bloqueia esse login do cliente, e então encontrei as informações oficiais sobre a introdução do max_connect_errors, como mostrado abaixo, o MySQL 5.6/5.7 é o mesmo Se mais do que esse número de solicitações de conexão sucessivas de um host forem interrompidas sem uma conexão bem-sucedida, o servidor bloqueia esse host de novas conexões. Você pode desbloquear hosts bloqueados limpando o cache do host. Para isso, emita uma instrução FLUSH HOSTS ou execute um comando mysqladmin flush-hosts. Se uma conexão for estabelecida com sucesso em menos de max_connect_errors tentativas após uma conexão anterior ter sido interrompida, a contagem de erros para o host é reduzida a zero. No entanto, uma vez que um host é bloqueado, esvaziar o cache do host é a única forma de desbloqueá-lo. O padrão é 100. Como mostrado acima, a tradução é aproximadamente a seguinte: Se o servidor MySQL receber requisições consecutivas do mesmo host, e todas essas requisições consecutivas forem interrompidas sem estabelecer uma conexão com sucesso, quando o valor acumulado dessas requisições consecutivas for maior que o valor max_connect_errors set, o servidor MySQL bloqueará todas as requisições subsequentes desse host. Acredito que, quando você vir essa informação no início, também será atacado“Muitas solicitações de conexão sucessivas de um host são interrompidas sem uma conexão bem-sucedida”Confuso, na verdade, isso ocorre porque a conexão do banco de dados é abortada devido a anomalias na rede. Procurei por essas informações na Internet: Parece haver confusão em torno dessa variável. Ele não bloqueia realmente hosts por senhas inválidas repetidas, mas sim por conexões abortadas devido a erros de rede. Então podemos experimentar e verificar por conta própria para descobrir qual delas está correta. Crie uma conta de teste no banco de dados MySQL e, em seguida, definimos a variável max_connect_errors como3. Depois, usamos outra máquina de teste para conectar ao banco de dados MySQL com a senha errada, como mostrado abaixo, mesmo que as três senhas anteriores erradas sejam inseridas, a quarta entrada não apresenta o erro acima.Assim, você pode descartar que essa variável tenha algo a ver com a entrada de senha errada. [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Digite a senha: ERRO 1045 (28000): Acesso negado para usuário 'test'@'mytestlnx02' (usando senha: SIM) [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Digite a senha: ERRO 1045 (28000): Acesso negado para usuário 'test'@'mytestlnx02' (usando senha: SIM) [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Digite a senha: ERRO 1045 (28000): Acesso negado para usuário 'test'@'mytestlnx02' (usando senha: SIM) [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Digite a senha: ERRO 1045 (28000): Acesso negado para usuário 'test'@'mytestlnx02' (usando senha: SIM) [root@mytestlnx02 tmp] # Na verdade, se um IP inserir uma senha incorreta, o MySQL a gravará na tabela host_cache sob o banco de dados performance_schema. Ele é registrado cumulativamente em COUNT_AUTHENTICATION_ERRORS campos da seguinte forma:
De acordo com as informações oficiais, o campo host_cache é estatisticamente considerado como“Obstrução”de erros de conexão (avaliados com base em max_connect_errors variáveis do sistema). Apenas erros de handshake de protocolo são contabilizados e são usados apenas para hosts autenticados (HOST_VALIDATED = SIM). SUM_CONNECT_ERRORS O número de erros de conexão considerados "bloqueadores" (avaliados em relação aomax_connect_errorsvariável do sistema). Apenas erros de handshake de protocolo são contados, e somente para hosts que passaram pela validação (HOST_VALIDATED = SIM). MySQLO cliente precisa iniciar um protocolo de aperto de mão de três tempos para estabelecer uma conexão com o banco de dados; em circunstâncias normais, esse tempo é muito curto, mas assim que a anomalia da rede, o timeout da rede e outros fatores aparecem, isso fará com que o protocolo de aperto de mão não seja concluído, o MySQL tem um parâmetro connect_timeout, é o tempo para o servidor MySQL processar o MySQL aguardar a conexão ser estabelecida, em segundos. Se o handshake do protocolo ainda não for concluído após o período de connect_timeout, o cliente MySQL receberá uma exceção com uma mensagem de exceção semelhante a: Perda de conexão com o servidor MySQL em 'XXX', erro do sistema: errno, a variável tem como padrão 10 segundos:
Vamos construir um caso em que a conexão do banco de dados é interrompida causada por um tempo de espera da rede, usamos os comandos netem e tc no Linux para simular o caso de atraso de transmissão da rede em um ambiente complexo, após as seguintes configurações, neste momento do servidor de teste para acessar o servidor MySQL, haverá um atraso de 11 segundos: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bytes de dados. 64 bytes a partir de 10.20.57.24: icmp_seq=1 TTL=62 tempo=0,251 ms 64 bytes a partir de 10.20.57.24: icmp_seq=2 TTL=62 tempo=0,330 ms 64 bytes de 10.20.57.24: icmp_seq=3 TTL=62 tempo=0,362 ms 64 bytes a partir de 10.20.57.24: icmp_seq=4 TTL=62 tempo=0,316 ms 64 bytes a partir de 10.20.57.24: icmp_seq=5 TTL=62 tempo=0,281 ms 64 bytes a partir de 10.20.57.24: icmp_seq=6 ttl=62 tempo=0,377 ms ^C --- 20.10.57.24 estatísticas de ping --- 6 pacotes transmitidos, 6 recebidos, 0% de perda de pacotes, tempo 5716ms RTT min/AVG/MAX/mdev = 0,251/0,319/0,377/0,047 ms [root@gettestlnx02 ~]# TC qdisc add dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bytes de dados. 64 bytes a partir de 10.20.57.24: icmp_seq=1 TTL=62 tempo=11000 ms 64 bytes a partir de 10.20.57.24: icmp_seq=2 TTL=62 tempo=11000 ms 64 bytes a partir de 10.20.57.24: icmp_seq=3 TTL=62 tempo=11000 ms 64 bytes a partir de 10.20.57.24: icmp_seq=4 TTL=62 tempo=11000 ms 64 bytes a partir de 10.20.57.24: icmp_seq=5 TTL=62 tempo=11000 ms 64 bytes a partir de 10.20.57.24: icmp_seq=6 TTL=62 tempo=11000 ms 64 bytes de 10.20.57.24: icmp_seq=7 TTL=62 tempo=11000 ms
Nós nos conectamos ao banco de dados MySQL no servidor de teste gettestlnx02 conforme mostrado abaixo (note que, se você estiver se conectando a esse servidor via ssh, ele será bem lento para operar no gettestlnx02 neste momento.) Claro, você também pode simular a latência de rede no servidor MySQL, ou pode reduzir tanto a latência connect_timeout quanto a da rede) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Digite a senha: ERRO 2013 (HY000): Perda de conexão com o servidor MySQL ao 'ler pacote de autorização', erro do sistema: 0 [root@gettestlnx02 ~] # Como mostrado acima, devido ao atraso de rede de mais de 10 segundos, a conexão com o MySQL falhou; nesse momento, quando você consulta a tabela host_cache no servidor MySQL, verá que o SUM_CONNECT_ERRORS se tornou 1, e o COUNT_HANDSHAKE_ERRORS também mudou1.
Depois, jogamos assim três vezes repetidamente, e você verá que o SUM_CONNECT_ERRORS vira 3, e o COUNT_HANDSHAKE_ERRORS vira 3. Depois, usamos comandos netem e tc para cancelar a simulação de latência de rede no servidor de teste, e então vamos para a conexão de teste com o banco de dados MySQL, como mostrado no teste a seguir: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Digite a senha: ERRO 1129 (HY000): O host '192.168.27.180' está bloqueado devido a muitos erros de conexão; desbloquear com 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
Atualmente, ele pode ser construído“ERRO 1129 (HY000): O host '192.168.27.180' está bloqueado devido a muitos erros de conexão; desbloquear com 'mysqladmin flush-hosts'”Errado. solução ERRO 1129 resolvido (00000): O host 'xxx' está bloqueado devido a muitos erros de conexão. Existem muitas formas de obter o erro Unlock com 'mysqladmin flush-hosts', mas algumas são temporárias. O plano temporário é que os indicadores não abordem a causa raiz. A chave é corrigir erros de rede (que frequentemente exigem consultores de administradores de rede ou administradores de sistema) Solução alternativa: 1, defina o valor da variável max_connection_errors para um valor maior
Essa solução temporária é apenas uma condição de disparo de atraso para que a IP seja proibida, e em casos complexos ou com alta concorrência, é necessário definir um valor alto, caso contrário ela será facilmente acionada novamente. Além disso, variáveis só entram em vigor no ambiente atual e expiram se forem reiniciadas. 2: usohospedeiros flush mysql> hospedeiros flush; Consulta OK, 0 linhas afetadas (0,00 seg) mysql> selecione * de performance_schema.host_cache; Conjunto vazio (0,00 seg) mysql> Claro, você também pode usar o comando mysqladmin flush-hosts para limpar as informações do cache do host [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Digite a senha: Então, o que é host cache? A introdução oficial é a seguinte: O servidor MySQL mantém um cache de host na memória que contém informações sobre clientes: endereço IP, nome do host e informações de erro. O servidor usa esse cache para conexões TCP não locais. Ele não usa o cache para conexões TCP estabelecidas usando um endereço de interface loopback (127.0.0.1 ou ::1), nem para conexões estabelecidas usando um arquivo de soquete Unix, pipe nomeado ou compartilhado memória. Em termos simples, o servidor MySQL mantém um cache na memória contendo informações do cliente: endereço IP, nome do host, mensagem de erro, etc. O servidor armazena em cache informações de conexão TCP não locais. Ele não armazena em cache conexões TCP feitas usando endereços de interface loopback (127.0.0.1 ou::1), nem conexões feitas usando arquivos de socket Unix, pipelines nomeados ou memória compartilhada. As informações do cache do host podem ser consultadas através da tabela host_cache no banco de dados performance_schema. 3: Defina a variável host_cache_size para0 Na verdade, eu diria que essa é a solução mais pouco confiável, só para fazer o servidor MySQL não registrar as informações do cache do host. Esse método pode ser completamente ignorado.
| 
Publicado em 08/04/2019 11:01:48
|
|
|
|
