Etapas a serem seguidas se você tiver uma interrupção do MySQL

Uma interrupção do MySQL significa simplesmente que seu serviço MySQL não está acessível ou não responde da perspectiva do outro. As interrupções podem ser originadas por várias causas possíveis.

• Problema de rede - problema de conectividade, switch, roteamento, resolvedor, nível de balanceador de carga.
• Problema de recursos - se você atingiu o limite ou gargalo de recursos.
• Configuração incorreta - Permissão ou propriedade incorreta, variável desconhecida, senha incorreta, privilégio alterado.
• Bloqueio - Bloqueio global ou de tabela impede que outras pessoas acessem os dados.

Nesta postagem do blog, veremos algumas etapas a serem seguidas se você estiver tendo uma interrupção do MySQL (ambiente Linux).

Etapa um:obter o código de erro

Quando houver uma interrupção, seu aplicativo lançará alguns erros e exceções. Esses erros geralmente vêm com um código de erro, que lhe dará uma ideia aproximada do que você está enfrentando e o que fazer a seguir para solucionar o problema e recuperar a interrupção.

Para obter mais detalhes sobre o erro, verifique as páginas MySQL Error Code ou MariaDB Error Code, respectivamente, para descobrir o que o erro significa.

Etapa dois:o servidor MySQL está rodando?

Entre no servidor via terminal e veja se o daemon MySQL está rodando e escutando a porta correta. No Linux, você faria o seguinte:

Primeiro, verifique o processo do MySQL:

$ ps -ef | grep -i mysql

Você deve receber algo em troca. Caso contrário, o MySQL não está em execução. Se o MySQL não estiver rodando, tente iniciá-lo:

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

Se você estiver vendo um erro no passo acima, você deve olhar o log de erros do MySQL, que varia dependendo do sistema operacional e da configuração da variável MySQL para log_error no arquivo de configuração do MySQL. Para servidor baseado em RedHat, o arquivo geralmente está localizado em:

$ cat /var/log/mysqld.log

Preste atenção às linhas mais recentes com nível de log "[Error]". Algumas linhas marcadas com "[Aviso]" podem indicar alguns problemas, mas são bastante incomuns. Na maioria das vezes, problemas de configuração e recursos incorretos podem ser detectados a partir daqui.

Se o MySQL estiver em execução, verifique se está escutando na porta correta:

$ netstat -tulpn | grep -i mysql

tcp6       0 0 :::3306                 :::* LISTEN   1089/mysqld

Você obteria o nome do processo "mysqld", escutando em todas as interfaces (:::3306 ou 0.0.0.0:3306) na porta 3306 com PID 1089 e o estado é "LISTEN". Se você vir a linha acima mostra 127.0.0.1:3306, o MySQL está apenas escutando localmente. Você pode precisar alterar o valor bind_address no arquivo de configuração do MySQL para ouvir todos os endereços IP ou simplesmente comentar na linha.

Etapa três:verifique se há problemas de conectividade

Se o servidor MySQL está rodando bem sem erros dentro do log de erros do MySQL, a chance de que problemas de conectividade estejam acontecendo é bem alta. Comece verificando a conectividade com o host via ping (se o ICMP estiver ativado) e telnet para o servidor MySQL a partir do servidor de aplicativos:

(application-server)$ ping db1.mydomain.com

(application-server)$ telnet db1.mydomain.com 3306

Trying db1.mydomain.com...

Connected to 192.168.0.16.

Escape character is '^]'.

O

5.6.46-86.2sN&nz9NZ�32?&>H,EV`_;mysql_native_password

Você deve ver algumas linhas na saída do telnet se puder se conectar à porta MySQL. Agora, tente mais uma vez usando o cliente MySQL do servidor de aplicativos:

(application-server)$ mysql -u db_user -p -h db1.mydomain.com -P3306

ERROR 1045 (28000): Access denied for user 'db_user'@'db1.mydomain.com' (using password: YES)

No exemplo acima, o erro nos dá algumas informações sobre o que fazer em seguida. O acima provavelmente porque alguém mudou a senha para "db_user" ou a senha para este usuário expirou. Este é um comportamento bastante normal do MySQL 5.7. 4 e superior, onde a política de expiração automática de senha é habilitada por padrão com um limite de 360 ​​dias - o que significa que todas as senhas expirarão uma vez por ano.

Etapa Quatro:Verifique a Lista de Processos do MySQL

Se o MySQL estiver funcionando bem sem problemas de conectividade, verifique a lista de processos do MySQL para ver quais processos estão em execução no momento:

mysql> SHOW FULL PROCESSLIST;

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| Id  | User | Host      | db | Command | Time | State | Info                  | Rows_sent | Rows_examined |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| 117 | root | localhost | NULL | Query   | 0 | init | SHOW FULL PROCESSLIST |       0 | 0 |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

1 row in set (0.01 sec)

Preste atenção à coluna Info e Hora. Algumas operações do MySQL podem ser destrutivas o suficiente para fazer o banco de dados travar e parar de responder. As seguintes instruções SQL, se executadas, podem bloquear o acesso de outras pessoas ao banco de dados ou à tabela (o que pode causar uma breve interrupção do serviço MySQL da perspectiva do aplicativo):

• LIXAR TABELAS COM BLOQUEIO DE LEITURA
• BLOQUEAR TABELA ...
• ALTER TABLE ...

Algumas transações de longa execução também podem paralisar outras, o que eventualmente causaria tempos limite para outras transações aguardando para acessar os mesmos recursos. Você pode eliminar a transação ofensiva para permitir que outros acessem as mesmas linhas ou tentar novamente as transações de enfileiramento após a conclusão da transação longa.

Conclusão

O monitoramento proativo é realmente importante para minimizar o risco de interrupção do MySQL. Se seu banco de dados é gerenciado pelo ClusterControl, todos os aspectos mencionados estão sendo monitorados automaticamente sem nenhuma configuração adicional do usuário. Você receberá alarmes em sua caixa de entrada para detecções de anomalias, como consultas de longa duração, configuração incorreta do servidor, recursos excedendo o limite e muito mais. Além disso, o ClusterControl tentará automaticamente recuperar seu serviço de banco de dados se algo der errado com o host ou a rede.

Você também pode aprender mais sobre MySQL e MariaDB Disaster Recovery lendo nosso whitepaper.