Ett MySQL-avbrott betyder helt enkelt att din MySQL-tjänst inte är tillgänglig eller inte svarar ur den andras perspektiv. Avbrott kan bero på en massa möjliga orsaker...
- Nätverksproblem – anslutningsproblem, switch, routing, resolver, lastbalanseringsnivå.
- Resursproblem – om du har nått resursgränsen eller flaskhalsen.
- Felkonfiguration – Fel behörighet eller äganderätt, okänd variabel, fel lösenord, behörighet ändrad.
- Låsning – Globalt eller tabelllås hindrar andra från att komma åt data.
I det här blogginlägget kommer vi att titta på några steg att ta om du har ett MySQL-avbrott (Linux-miljö).
Steg ett:Hämta felkoden
När du har ett avbrott kommer din applikation att kasta ut några fel och undantag. Dessa fel kommer vanligtvis med en felkod, som ger dig en ungefärlig uppfattning om vad du står inför och vad du ska göra härnäst för att felsöka problemet och återställa avbrottet.
För att få mer information om felet, kolla MySQL Error Code respektive MariaDB Error Code-sidorna för att ta reda på vad felet betyder.
Steg två:Körs MySQL-servern?
Logga in på servern via terminalen och se om MySQL-demonen körs och lyssnar på rätt port. I Linux skulle man göra följande:
Kontrollera först MySQL-processen:
$ ps -ef | grep -i mysqlDu borde få något tillbaka. Annars körs inte MySQL. Om MySQL inte körs, försök att starta upp det:
$ systemctl start mysql # systemd
$ service mysql start # sysvinit/upstart
$ mysqld_safe # manualOm du ser ett fel i steget ovan, bör du titta på MySQL-felloggen, som varierar beroende på operativsystemet och MySQL-variabelkonfigurationen för log_error i MySQL-konfigurationsfilen. För RedHat-baserad server finns filen vanligtvis på:
$ cat /var/log/mysqld.logVar uppmärksam på de senaste raderna med loggnivån "[Error]". Vissa rader märkta med "[Varning]" kan indikera vissa problem, men de är ganska ovanliga. För det mesta kan felkonfiguration och resursproblem upptäckas härifrån.
Om MySQL körs, kontrollera om den lyssnar på rätt port:
$ netstat -tulpn | grep -i mysql
tcp6 0 0 :::3306 :::* LISTEN 1089/mysqldDu skulle få processnamnet "mysqld", lyssna på alla gränssnitt (:::3306 eller 0.0.0.0:3306) på port 3306 med PID 1089 och tillståndet är "LYSNA". Om du ser att ovanstående rad visar 127.0.0.1:3306, lyssnar MySQL bara lokalt. Du kan behöva ändra bind_address-värdet i MySQL-konfigurationsfilen för att lyssna på alla IP-adresser, eller helt enkelt kommentera på raden.
Steg tre:Kontrollera om det finns anslutningsproblem
Om MySQL-servern fungerar bra utan fel i MySQL-felloggen är chansen att anslutningsproblem uppstår ganska stor. Börja med att kontrollera anslutningen till värden via ping (om ICMP är aktiverat) och telnet till MySQL-servern från applikationsservern:
(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 några rader i telnet-utgången om du kan ansluta till MySQL-porten. Försök nu en gång till genom att använda MySQL-klienten från applikationsservern:
(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 exemplet ovan ger felet oss lite information om vad vi ska göra härnäst. Ovanstående förmodligen för att någon har ändrat lösenordet för "db_user" eller att lösenordet för denna användare har gått ut. Detta är ett ganska normalt beteende från MySQL 5.7. 4 och högre, där policyn för automatisk utgång av lösenord är aktiverad som standard med en tröskel på 360 dagar - vilket innebär att alla lösenord kommer att upphöra att gälla en gång om året.
Steg fyra:Kontrollera MySQL-processlistan
Om MySQL fungerar bra utan anslutningsproblem, kontrollera MySQL-processlistan för att se vilka processer som körs för närvarande:
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)Var uppmärksam på kolumnen Info och Tid. Vissa MySQL-operationer kan vara tillräckligt destruktiva för att få databasen att stanna och sluta svara. Följande SQL-satser, om de körs, kan blockera andra att komma åt databasen eller tabellen (vilket kan leda till ett kort avbrott i MySQL-tjänsten ur applikationsperspektiv):
- SPOLA TABELLER MED LÄSSLÅS
- LÅS TABEL ...
- ÄNDRA TABELL ...
Vissa långvariga transaktioner kan även stoppa andra, vilket så småningom skulle orsaka timeout för andra transaktioner som väntar på att få tillgång till samma resurser. Du kan antingen döda den stötande transaktionen för att låta andra komma åt samma rader eller försöka kötransaktionerna igen efter att den långa transaktionen är klar.
Slutsats
Proaktiv övervakning är verkligen viktigt för att minimera risken för MySQL-avbrott. Om din databas hanteras av ClusterControl övervakas alla nämnda aspekter automatiskt utan någon ytterligare konfiguration från användaren. Du kommer att få larm i din inkorg för avvikelsedetektering som långvariga frågor, felkonfiguration av servern, resurs som överskrider tröskeln och många fler. Dessutom kommer ClusterControl automatiskt att försöka återställa din databastjänst om något går fel med värden eller nätverket.
Du kan också lära dig mer om MySQL &MariaDB Disaster Recovery genom att läsa vårt whitepaper.