Стъпки, които трябва да предприемете, ако имате прекъсване на MySQL

Прекъсване на MySQL просто означава, че вашата MySQL услуга не е достъпна или не реагира от гледна точка на другия. Прекъсванията могат да бъдат причинени от куп възможни причини...

• Проблем с мрежата – проблем със свързаността, превключвател, маршрутизиране, разделител, ниво на балансиране на натоварването.
• Проблем с ресурса – Независимо дали сте достигнали ограничението на ресурсите или сте имали затруднения.
• Грешна конфигурация – Грешно разрешение или собственост, неизвестна променлива, грешна парола, привилегия е променена.
• Заключване – Глобално или заключване на таблицата не позволяват на други да имат достъп до данните.

В тази публикация в блога ще разгледаме някои стъпки, които трябва да предприемете, ако имате прекъсване на MySQL (Linux среда).

Първа стъпка:Вземете кода на грешката

Когато имате прекъсване, приложението ви ще изведе някои грешки и изключения. Тези грешки обикновено идват с код за грешка, който ще ви даде груба представа какво сте изправени и какво да направите след това, за да отстраните проблема и да възстановите прекъсването.

За да получите повече подробности относно грешката, проверете съответно страниците с код за грешка MySQL или код за грешка MariaDB, за да разберете какво означава грешката.

Втора стъпка:MySQL сървърът работи ли?

Влезте в сървъра чрез терминал и вижте дали MySQL демонът работи и слуша правилния порт. В Linux човек би направил следното:

Първо, проверете процеса на MySQL:

$ ps -ef | grep -i mysql

Трябва да получите нещо в замяна. В противен случай MySQL не работи. Ако MySQL не работи, опитайте да го стартирате:

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

Ако виждате грешка в горната стъпка, трябва да погледнете дневника за грешки на MySQL, който варира в зависимост от операционната система и конфигурацията на променливата на MySQL за log_error в конфигурационния файл на MySQL. За сървър, базиран на RedHat, файлът обикновено се намира на адрес:

$ cat /var/log/mysqld.log

Обърнете внимание на най-новите редове с ниво на дневника „[Грешка]“. Някои редове, обозначени с "[Предупреждение]", могат да показват някои проблеми, но те са доста необичайни. През повечето време проблеми с грешната конфигурация и ресурсите могат да бъдат открити от тук.

Ако MySQL работи, проверете дали слуша правилния порт:

$ netstat -tulpn | grep -i mysql

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

Ще получите името на процеса "mysqld", слушане на всички интерфейси (:::3306 или 0.0.0.0:3306) на порт 3306 с PID 1089 и състоянието е "LISTEN". Ако видите, че горният ред показва 127.0.0.1:3306, MySQL слуша само локално. Може да се наложи да промените стойността на bind_address в конфигурационния файл на MySQL, за да слушате всички IP адреси, или просто да коментирате реда.

Стъпка трета:Проверете за проблеми със свързаността

Ако MySQL сървърът работи добре без грешка в регистъра за грешки на MySQL, вероятността да възникнат проблеми със свързаността е доста голяма. Започнете с проверка на свързаността към хоста чрез ping (ако ICMP е активиран) и telnet към MySQL сървъра от сървъра на приложения:

(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

Трябва да видите някои линии в изхода на telnet, ако можете да се свържете с порта MySQL. Сега опитайте още веднъж, като използвате MySQL клиент от сървъра на приложения:

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

В горния пример грешката ни дава малко информация какво да правим по-нататък. Горното вероятно защото някой е променил паролата за "db_user" или паролата за този потребител е изтекла. Това е доста нормално поведение от MySQL 5.7. 4 и по-горе, където политиката за автоматично изтичане на паролата е активирана по подразбиране с праг от 360 дни – което означава, че всички пароли ще изтекат веднъж годишно.

Стъпка четвърта:Проверете списъка с процеси на MySQL

Ако MySQL работи добре без проблеми със свързаността, проверете списъка с процеси на MySQL, за да видите кои процеси се изпълняват в момента:

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)

Обърнете внимание на колоната Информация и Време. Някои MySQL операции могат да бъдат достатъчно разрушителни, за да накарат базата данни да спре и да не реагира. Следните SQL оператори, ако се изпълняват, биха могли да блокират други за достъп до базата данни или таблицата (което може да доведе до кратко прекъсване на услугата MySQL от гледна точка на приложението):

• ФЛУШВАНЕ НА ТАБЛИЦИТЕ СЪС ЗАКЛЮЧВАНЕ НА ЧЕТЕНЕ
• ЗАКЛЮЧВАНЕ НА ТАБЛИЦА ...
• ПРОМЕНЯ ТАБЛИЦА ...

Някои продължително изпълнявани транзакции също могат да спрат други, което в крайна сметка ще доведе до изчакване на други транзакции, чакащи за достъп до същите ресурси. Можете или да прекратите обидната транзакция, за да позволите на другите да имат достъп до същите редове, или да опитате отново транзакциите в опашката, след като дългата транзакция приключи.

Заключение

Проактивното наблюдение е наистина важно за минимизиране на риска от прекъсване на MySQL. Ако вашата база данни се управлява от ClusterControl, всички споменати аспекти се наблюдават автоматично без допълнителна конфигурация от потребителя. Ще получавате аларми във входящата си кутия за откриване на аномалии като продължителни заявки, неправилна конфигурация на сървъра, ресурс надвишаващ праг и много други. Освен това ClusterControl автоматично ще се опита да възстанови вашата услуга за база данни, ако нещо се обърка с хоста или мрежата.

Можете също да научите повече за MySQL и MariaDB Disaster Recovery, като прочетете нашата бяла книга.