MariaDB
 sql >> Database >  >> RDS >> MariaDB

Passaggi da eseguire in caso di interruzione di MySQL

Un'interruzione di MySQL significa semplicemente che il tuo servizio MySQL non è accessibile o non risponde dal punto di vista dell'altro. Le interruzioni possono essere originate da una serie di possibili cause..

  • Problema di rete:problema di connettività, switch, routing, resolver, livello di bilanciamento del carico.
  • Problema con le risorse:se hai raggiunto il limite o il collo di bottiglia delle risorse.
  • Errore di configurazione:autorizzazione o proprietà errate, variabile sconosciuta, password errata, privilegio modificato.
  • Blocco:il blocco globale o della tabella impedisce ad altri di accedere ai dati.

In questo post del blog, esamineremo alcuni passaggi da eseguire se si verifica un'interruzione di MySQL (ambiente Linux).

Fase uno:ottieni il codice di errore

Quando si verifica un'interruzione, l'applicazione emetterà alcuni errori ed eccezioni. Questi errori comunemente vengono forniti con un codice di errore, che ti darà un'idea approssimativa di cosa stai affrontando e cosa fare dopo per risolvere il problema e ripristinare l'interruzione.

Per avere maggiori dettagli sull'errore, controlla rispettivamente le pagine MySQL Error Code o MariaDB Error Code per capire cosa significa l'errore.

Fase due:il server MySQL è in esecuzione?

Accedi al server tramite terminale e verifica se il demone MySQL è in esecuzione e ascolta la porta corretta. In Linux, si dovrebbe fare quanto segue:

In primo luogo, controlla il processo MySQL:

$ ps -ef | grep -i mysql

Dovresti ottenere qualcosa in cambio. In caso contrario, MySQL non è in esecuzione. Se MySQL non è in esecuzione, prova ad avviarlo:

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

Se vedi un errore nel passaggio precedente, dovresti guardare il log degli errori di MySQL, che varia a seconda del sistema operativo e della configurazione della variabile MySQL per log_error nel file di configurazione di MySQL. Per il server basato su RedHat, il file si trova comunemente in:

$ cat /var/log/mysqld.log

Prestare attenzione alle righe più recenti con livello di registro "[Errore]". Alcune righe etichettate con "[Avviso]" potrebbero indicare alcuni problemi, ma sono piuttosto rari. Nella maggior parte dei casi, da qui è possibile rilevare errori di configurazione e risorse.

Se MySQL è in esecuzione, controlla se sta ascoltando la porta corretta:

$ netstat -tulpn | grep -i mysql

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

Otterresti il ​​nome del processo "mysqld", in ascolto su tutte le interfacce (:::3306 o 0.0.0.0:3306) sulla porta 3306 con PID 1089 e lo stato è "LISTEN". Se vedi la riga sopra mostra 127.0.0.1:3306, MySQL sta ascoltando solo localmente. Potrebbe essere necessario modificare il valore bind_address nel file di configurazione di MySQL per ascoltare tutti gli indirizzi IP o semplicemente commentare la riga.

Fase tre:verifica problemi di connettività

Se il server MySQL funziona correttamente senza errori nel log degli errori MySQL, la possibilità che si verifichino problemi di connettività è piuttosto alta. Inizia controllando la connettività all'host tramite ping (se ICMP è abilitato) e telnet al server MySQL dal server delle applicazioni:

(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

Dovresti vedere alcune righe nell'output di telnet se riesci a connetterti alla porta MySQL. Ora, prova ancora una volta utilizzando il client MySQL dal server delle applicazioni:

(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)

Nell'esempio sopra, l'errore ci fornisce alcune informazioni su cosa fare dopo. Quanto sopra probabilmente perché qualcuno ha cambiato la password per "db_user" o la password per questo utente è scaduta. Questo è un comportamento piuttosto normale da MySQL 5.7. 4 e versioni successive, dove il criterio di scadenza automatica delle password è abilitato per impostazione predefinita con una soglia di 360 giorni, il che significa che tutte le password scadranno una volta all'anno.

Fase quattro:controlla MySQL Processlist

Se MySQL funziona correttamente senza problemi di connettività, controlla l'elenco dei processi MySQL per vedere quali processi sono attualmente in esecuzione:

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)

Fai attenzione alla colonna Info e Ora. Alcune operazioni MySQL potrebbero essere sufficientemente distruttive da far sì che il database si blocchi e non risponda. Le seguenti istruzioni SQL, se in esecuzione, potrebbero impedire ad altri di accedere al database o alla tabella (il che potrebbe causare una breve interruzione del servizio MySQL dal punto di vista dell'applicazione):

  • TAVOLI FLUSH CON BLOCCO LETTURA
  • BLOCCO TABELLA ...
  • ALTER TABLE ...

Alcune transazioni di lunga durata potrebbero anche bloccarne altre, il che alla fine causerebbe timeout ad altre transazioni in attesa di accedere alle stesse risorse. Puoi interrompere la transazione offensiva per consentire ad altri di accedere alle stesse righe o riprovare le transazioni di accodamento al termine della transazione lunga.

Conclusione

Il monitoraggio proattivo è molto importante per ridurre al minimo il rischio di interruzioni di MySQL. Se il tuo database è gestito da ClusterControl, tutti gli aspetti citati vengono monitorati automaticamente senza alcuna configurazione aggiuntiva da parte dell'utente. Riceverai allarmi nella tua casella di posta per rilevamenti di anomalie come query di lunga durata, configurazione errata del server, superamento della soglia delle risorse e molti altri. Inoltre, ClusterControl tenterà automaticamente di ripristinare il servizio del database se qualcosa va storto con l'host o la rete.

Puoi anche saperne di più su MySQL e MariaDB Disaster Recovery leggendo il nostro whitepaper.