Kroky, které je třeba podniknout, pokud dojde k výpadku MySQL

Výpadek MySQL jednoduše znamená, že vaše služba MySQL není přístupná nebo nereaguje z pohledu druhého. Výpadky mohou být způsobeny řadou možných příčin..

• Problém se sítí – Problém s připojením, přepínačem, směrováním, překladačem, úrovní vyvažování zátěže.
• Problém se zdroji – zda ​​jste dosáhli limitu zdrojů nebo úzkého místa.
• Nesprávná konfigurace – nesprávné oprávnění nebo vlastnictví, neznámá proměnná, špatné heslo, oprávnění změněno.
• Uzamykání – Globální nebo tabulkový zámek brání ostatním v přístupu k datům.

V tomto příspěvku na blogu se podíváme na několik kroků, které je třeba podniknout, pokud máte výpadek MySQL (prostředí Linuxu).

První krok:Získejte kód chyby

Když dojde k výpadku, aplikace vyhodí některé chyby a výjimky. Tyto chyby obvykle přicházejí s kódem chyby, který vám poskytne přibližnou představu o tom, čemu čelíte a co dělat dále, abyste problém vyřešili a obnovili výpadek.

Chcete-li získat další podrobnosti o chybě, podívejte se na stránky Chybový kód MySQL nebo Chybový kód MariaDB, abyste zjistili, co chyba znamená.

Krok 2:Funguje server MySQL?

Přihlaste se k serveru přes terminál a zjistěte, zda běží démon MySQL a naslouchá na správném portu. V Linuxu byste udělali následující:

Nejprve zkontrolujte proces MySQL:

$ ps -ef | grep -i mysql

Měli byste na oplátku něco dostat. Jinak MySQL neběží. Pokud MySQL neběží, zkuste jej spustit:

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

Pokud ve výše uvedeném kroku vidíte chybu, měli byste se podívat na chybový protokol MySQL, který se liší v závislosti na operačním systému a konfiguraci proměnné MySQL pro log_error v konfiguračním souboru MySQL. U serveru založeného na RedHat se soubor běžně nachází na adrese:

$ cat /var/log/mysqld.log

Věnujte pozornost nejnovějším řádkům s úrovní protokolu "[Error]". Některé řádky označené "[Warning]" by mohly naznačovat nějaké problémy, ale ty jsou docela neobvyklé. Zde lze většinou zjistit nesprávnou konfiguraci a problémy se zdroji.

Pokud MySQL běží, zkontrolujte, zda naslouchá správnému portu:

$ netstat -tulpn | grep -i mysql

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

Získali byste název procesu "mysqld", naslouchající na všech rozhraních (:::3306 nebo 0.0.0.0:3306) na portu 3306 s PID 1089 a stav je "LISTEN". Pokud výše uvedený řádek ukazuje 127.0.0.1:3306, MySQL naslouchá pouze lokálně. Možná budete muset změnit hodnotu bind_address v konfiguračním souboru MySQL, abyste mohli poslouchat všechny IP adresy, nebo jednoduše okomentovat řádek.

Krok 3:Zkontrolujte problémy s připojením

Pokud server MySQL běží správně a bez chyb v protokolu chyb MySQL, je šance, že se vyskytnou problémy s připojením, poměrně vysoká. Začněte kontrolou připojení k hostiteli pomocí příkazu ping (pokud je povoleno ICMP) a telnetu k serveru MySQL z aplikačního serveru:

(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

Měli byste vidět nějaké řádky ve výstupu telnetu, pokud se můžete připojit k portu MySQL. Nyní to zkuste ještě jednou pomocí klienta MySQL z aplikačního serveru:

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

Ve výše uvedeném příkladu nám chyba poskytuje informace o dalším postupu. Výše uvedené pravděpodobně proto, že někdo změnil heslo pro "db_user" nebo vypršela platnost hesla tohoto uživatele. Toto je poměrně normální chování z MySQL 5.7. 4 a vyšší, kde je zásada automatického vypršení platnosti hesla ve výchozím nastavení povolena s prahovou hodnotou 360 dní – což znamená, že platnost všech hesel vyprší jednou ročně.

Krok čtyři:Zkontrolujte seznam procesů MySQL

Pokud MySQL běží správně bez problémů s připojením, zkontrolujte seznam procesů MySQL a zjistěte, jaké procesy aktuálně běží:

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ěnujte pozornost sloupci Informace a čas. Některé operace MySQL by mohly být natolik destruktivní, že by se databáze zastavila a přestala reagovat. Pokud jsou spuštěny následující příkazy SQL, mohly by ostatním zablokovat přístup k databázi nebo tabulce (což by mohlo způsobit krátký výpadek služby MySQL z pohledu aplikace):

• SPLACHUJTE STOLY POMOCÍ ZÁMKU ČTENÍ
• ZAMKNOUT TABULKU ...
• ALTER TABLE ...

Některé dlouho běžící transakce by také mohly zastavit jiné, což by nakonec způsobilo časový limit pro jiné transakce čekající na přístup ke stejným zdrojům. Můžete buď urážlivou transakci ukončit a umožnit tak ostatním přístup ke stejným řádkům, nebo opakovat transakce ve frontě po dokončení dlouhé transakce.

Závěr

Proaktivní monitorování je opravdu důležité pro minimalizaci rizika výpadku MySQL. Pokud je vaše databáze spravována pomocí ClusterControl, jsou všechny zmíněné aspekty monitorovány automaticky bez jakékoli další konfigurace ze strany uživatele. Do vaší doručené pošty budete dostávat alarmy pro detekci anomálií, jako jsou dlouhé dotazy, chybná konfigurace serveru, překročení prahové hodnoty zdrojů a mnoho dalších. Navíc se ClusterControl automaticky pokusí obnovit vaši databázovou službu, pokud se něco pokazí s hostitelem nebo sítí.

Více o MySQL a MariaDB Disaster Recovery se také můžete dozvědět v našem whitepaperu.