Een MySQL-storing betekent simpelweg dat uw MySQL-service niet toegankelijk is of niet reageert vanuit het perspectief van de ander. Storingen kunnen worden veroorzaakt door een heleboel mogelijke oorzaken..
- Netwerkprobleem - verbindingsprobleem, switch, routering, resolver, load-balancer-laag.
- Probleem met bronnen - Of je de limiet of bottleneck hebt bereikt.
- Onjuiste configuratie - Verkeerde toestemming of eigendom, onbekende variabele, verkeerd wachtwoord, privilege gewijzigd.
- Vergrendelen - Globale of tabelvergrendeling voorkomt dat anderen toegang krijgen tot de gegevens.
In deze blogpost bekijken we enkele stappen die u kunt nemen als u een MySQL-storing heeft (Linux-omgeving).
Stap één:de foutcode ophalen
Als je een storing hebt, zal je applicatie enkele fouten en uitzonderingen weggooien. Deze fouten worden meestal geleverd met een foutcode, die u een globaal idee geeft van wat u tegenkomt en wat u vervolgens moet doen om het probleem op te lossen en de storing te herstellen.
Voor meer informatie over de fout kunt u de pagina's MySQL-foutcode of MariaDB-foutcode raadplegen om erachter te komen wat de fout betekent.
Stap twee:draait de MySQL-server?
Log in op de server via terminal en kijk of MySQL-daemon actief is en naar de juiste poort luistert. In Linux zou men het volgende doen:
Controleer eerst het MySQL-proces:
$ ps -ef | grep -i mysql
Je zou er iets voor terug moeten krijgen. Anders is MySQL niet actief. Als MySQL niet actief is, probeer het dan op te starten:
$ systemctl start mysql # systemd
$ service mysql start # sysvinit/upstart
$ mysqld_safe # manual
Als je een fout ziet in de bovenstaande stap, moet je het MySQL-foutlogboek bekijken, dat varieert afhankelijk van het besturingssysteem en de MySQL-variabeleconfiguratie voor log_error in het MySQL-configuratiebestand. Voor op RedHat gebaseerde servers bevindt het bestand zich gewoonlijk op:
$ cat /var/log/mysqld.log
Let op de meest recente regels met logniveau "[Error]". Sommige regels met het label "[Waarschuwing]" kunnen wijzen op problemen, maar die zijn vrij ongebruikelijk. Meestal kunnen misconfiguraties en problemen met bronnen hier worden gedetecteerd.
Als MySQL actief is, controleer dan of het naar de juiste poort luistert:
$ netstat -tulpn | grep -i mysql
tcp6 0 0 :::3306 :::* LISTEN 1089/mysqld
Je zou de procesnaam "mysqld" krijgen, luisterend op alle interfaces (:::3306 of 0.0.0.0:3306) op poort 3306 met PID 1089 en de status is "LISTEN". Als je ziet dat de bovenstaande regel 127.0.0.1:3306 toont, luistert MySQL alleen lokaal. Mogelijk moet u de waarde bind_address in het MySQL-configuratiebestand wijzigen om naar alle IP-adressen te luisteren, of gewoon commentaar geven op de regel.
Stap drie:controleer op verbindingsproblemen
Als de MySQL-server goed werkt zonder fouten in het MySQL-foutlogboek, is de kans dat er verbindingsproblemen optreden vrij groot. Begin met het controleren van de verbinding met de host via ping (als ICMP is ingeschakeld) en telnet naar de MySQL-server vanaf de applicatieserver:
(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
U zou enkele regels in de telnet-uitvoer moeten zien als u verbinding kunt maken met de MySQL-poort. Probeer het nu nog een keer door de MySQL-client van de applicatieserver te gebruiken:
(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)
In het bovenstaande voorbeeld geeft de fout ons een beetje informatie over wat we nu moeten doen. Het bovenstaande waarschijnlijk omdat iemand het wachtwoord voor "db_user" heeft gewijzigd of het wachtwoord voor deze gebruiker is verlopen. Dit is een vrij normaal gedrag van MySQL 5.7. 4 en hoger, waar het beleid voor het automatisch verlopen van wachtwoorden standaard is ingeschakeld met een drempel van 360 dagen, wat inhoudt dat alle wachtwoorden één keer per jaar verlopen.
Stap vier:controleer de MySQL-proceslijst
Als MySQL goed werkt zonder verbindingsproblemen, controleer dan de MySQL-proceslijst om te zien welke processen momenteel worden uitgevoerd:
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)
Let op de kolom Info en Tijd. Sommige MySQL-bewerkingen kunnen zo destructief zijn dat de database vastloopt en niet meer reageert. De volgende SQL-instructies kunnen, indien actief, anderen de toegang tot de database of tabel blokkeren (wat een korte onderbreking van de MySQL-service zou kunnen veroorzaken vanuit het perspectief van de toepassing):
- TAFELS SPOELEN MET LEESVERGRENDELING
- VERGRENDELTABEL ...
- WIJZIG TABEL ...
Sommige langlopende transacties kunnen ook andere blokkeren, wat uiteindelijk zou leiden tot time-outs voor andere transacties die wachten op toegang tot dezelfde bronnen. U kunt de aanstootgevende transactie beëindigen om anderen toegang te geven tot dezelfde rijen of de transacties opnieuw in de wachtrij plaatsen nadat de lange transactie is afgelopen.
Conclusie
Proactieve monitoring is erg belangrijk om het risico op MySQL-storingen te minimaliseren. Als uw database wordt beheerd door ClusterControl, worden alle genoemde aspecten automatisch gecontroleerd zonder enige aanvullende configuratie door de gebruiker. U ontvangt alarmen in uw inbox voor anomaliedetecties zoals langlopende query's, verkeerde serverconfiguratie, overschrijding van de drempelwaarde van bronnen en nog veel meer. Bovendien zal ClusterControl automatisch proberen uw databaseservice te herstellen als er iets misgaat met de host of het netwerk.
Je kunt ook meer te weten komen over MySQL en MariaDB Disaster Recovery door onze whitepaper te lezen.