Et MySQL-udfald betyder simpelthen, at din MySQL-tjeneste ikke er tilgængelig eller ikke reagerer fra den andens perspektiv. Udfald kan skyldes en masse mulige årsager..
- Netværksproblem – forbindelsesproblem, switch, routing, resolver, load-balancer-niveau.
- Ressourceproblem – om du har nået ressourcegrænsen eller flaskehalsen.
- Forkert konfiguration - Forkert tilladelse eller ejerskab, ukendt variabel, forkert adgangskode, rettigheder ændret.
- Låsning - Global eller tabellås forhindrer andre i at få adgang til dataene.
I dette blogindlæg vil vi se på nogle trin, du skal tage, hvis du har et MySQL-udfald (Linux-miljø).
Trin et:Hent fejlkoden
Når du har et udfald, vil din applikation kaste nogle fejl og undtagelser ud. Disse fejl kommer ofte med en fejlkode, som vil give dig en grov idé om, hvad du står over for, og hvad du skal gøre for at fejlfinde problemet og gendanne udfaldet.
For at få flere detaljer om fejlen, tjek MySQL-fejlkode- eller MariaDB-fejlkodesiderne for at finde ud af, hvad fejlen betyder.
Trin to:Kører MySQL-serveren?
Log ind på serveren via terminalen og se om MySQL-dæmonen kører og lytter til den korrekte port. I Linux ville man gøre følgende:
Tjek først MySQL-processen:
$ ps -ef | grep -i mysqlDu burde få noget til gengæld. Ellers kører MySQL ikke. Hvis MySQL ikke kører, så prøv at starte det op:
$ systemctl start mysql # systemd
$ service mysql start # sysvinit/upstart
$ mysqld_safe # manualHvis du ser en fejl på ovenstående trin, bør du se på MySQL fejlloggen, som varierer afhængigt af operativsystemet og MySQL variabel konfiguration for log_error i MySQL konfigurationsfil. For RedHat-baserede servere er filen normalt placeret på:
$ cat /var/log/mysqld.logVær opmærksom på de seneste linjer med logniveau "[Fejl]". Nogle linjer mærket med "[Advarsel]" kunne indikere nogle problemer, men de er ret ualmindelige. Det meste af tiden kan fejlkonfiguration og ressourceproblemer opdages herfra.
Hvis MySQL kører, så tjek om det lytter til den korrekte port:
$ netstat -tulpn | grep -i mysql
tcp6 0 0 :::3306 :::* LISTEN 1089/mysqldDu får procesnavnet "mysqld", der lytter på alle grænseflader (:::3306 eller 0.0.0.0:3306) på port 3306 med PID 1089, og tilstanden er "LYT". Hvis du ser, at ovenstående linje viser 127.0.0.1:3306, lytter MySQL kun lokalt. Du skal muligvis ændre bind_address-værdien i MySQL-konfigurationsfilen for at lytte til alle IP-adresser eller blot kommentere på linjen.
Trin tre:Tjek for forbindelsesproblemer
Hvis MySQL-serveren kører fint uden fejl i MySQL-fejlloggen, er chancen for, at der opstår forbindelsesproblemer, ret stor. Start med at kontrollere forbindelsen til værten via ping (hvis ICMP er aktiveret) og telnet til MySQL-serveren fra applikationsserveren:
(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_passwordDu bør se nogle linjer i telnet-udgangen, hvis du kan få forbindelse til MySQL-porten. Prøv nu igen ved at bruge MySQL-klienten fra applikationsserveren:
(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)I ovenstående eksempel giver fejlen os en smule information om, hvad vi skal gøre nu. Ovenstående sandsynligvis fordi nogen har ændret adgangskoden til "db_user", eller adgangskoden til denne bruger er udløbet. Dette er en ret normal adfærd fra MySQL 5.7. 4 og derover, hvor den automatiske adgangskodeudløbspolitik er aktiveret som standard med en tærskel på 360 dage - hvilket betyder, at alle adgangskoder udløber en gang om året.
Trin fire:Tjek MySQL-proceslisten
Hvis MySQL kører fint uden forbindelsesproblemer, skal du tjekke MySQL-proceslisten for at se, hvilke processer der kører i øjeblikket:
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)Vær opmærksom på kolonnen Info og Tid. Nogle MySQL-operationer kan være destruktive nok til at få databasen til at gå i stå og ikke reagere. Følgende SQL-sætninger, hvis de kører, kan blokere andres adgang til databasen eller tabellen (hvilket kan medføre et kort afbrydelse af MySQL-tjenesten fra applikationsperspektivet):
- SKYL TABELLER MED LÆSELÅS
- LÅS TABEL ...
- ÆNDRINGSTABEL ...
Nogle langvarige transaktioner kan også stoppe andre, hvilket i sidste ende vil forårsage timeouts til andre transaktioner, der venter på at få adgang til de samme ressourcer. Du kan enten dræbe den stødende transaktion for at lade andre få adgang til de samme rækker eller prøve kø-transaktionerne igen, efter den lange transaktion er afsluttet.
Konklusion
Proaktiv overvågning er virkelig vigtig for at minimere risikoen for MySQL-udfald. Hvis din database administreres af ClusterControl, overvåges alle de nævnte aspekter automatisk uden yderligere konfiguration fra brugeren. Du vil modtage alarmer i din indbakke for afvigelser som f.eks. langvarige forespørgsler, serverfejlkonfiguration, ressource, der overskrider tærskelværdien og mange flere. Plus, ClusterControl vil automatisk forsøge at gendanne din databasetjeneste, hvis noget går galt med værten eller netværket.
Du kan også lære mere om MySQL &MariaDB Disaster Recovery ved at læse vores hvidbog.