Сьогодні спробував зайти на один з наших сайтів і побачив помилку WordPress про відсутнє підключення до бази даних. Таке інколи трапляється, сайт знаходиться на виділеному сервері і коли йде великий трафік сервер бази даних може підвиснути. Така проблема легко вирішується перезавантаженням сервера.
Але цього разу все було не так просто. Перезагрузка не дала ніякого результату і я пішов шукати проблему в логах.
/var/log/mysql сповістив мене про таку проблему:
Found invalid event sequence while recovering from binary log file './binlog.000514', between positions 8001557 and 8001716: Query_log_event containing `COMMIT` outside the boundary of a sequence of events representing an active transaction. The recovery process was stopped early and no transaction was recovered. Side effects may be transactions in an inconsistent state between the binary log and the storage engines, or transactions kept by storage engines in a prepared state (possibly holding locks). Either fix the issues with the binary log or, to release possibly acquired locks, disable the binary log server recovery. Note that disabling the binary log may lead to loss of transactions that were already acknowledged as successful to client connections and may have been replicated to other servers in the topology.
Як я потім розібрався на сервері закінчилась память і бінарний файл записався з помилкою, при старті сервера БД система цю помилку знаходила і зупинялась вказуючи на необхідність вирішити проблему.
Раніш в мене вже був досвід роботи з бінарними файлами MySQL – на одному із серверів дуже швидко закінчувалось місце на жорсткому диску. В процесі пошуку винуватця я вийшов на те, що система створювала багато бінарних файлів БД і вони зберігались на жорсткому диску, а оскільки їх розмір зазвичай не малий, вільне місце через це швидко закінчувалось.
Знаходяться бінарники за адресою:
/var/lib/mysql
Видаляти їх руками не можна – отримаєте помилки при запуску MySQL, для видалення цих файлів є спеціальна команда в самій базі.
Для цього логінимось в базу командою:
mysql -u root -p
Вводимо свій пароль користувача root бази даних і потім вводимо таку команду:
reset master;
Після цього всі бінарні файли буде видалено без шкоди для БД.
В моєму випадку проблема була в тому, що один із бінарних файлів було пошкоджено і база даних не запускалась, тож я не міг підключитись і провести очистку. Перевірити статус БД ви можете командою:
systemctl status mysql.service
Якщо все добре і сервер баз даних працює, ви побачите таке повідомлення:
Якщо ви бачите що база зупинена і не активна, то треба спочатку її запустити.
В моєму випадку проблема була із конкретним файлом, якось його редагувати не було сенсу, щоб виправити помилку, переміщення файлу не давало результату, бо система шукала його при запуску і коли не знаходила, БД зупинялась з помилкою, вказуючи на відсутність файлу в логах.
Рішення пришло спонтанно. На счастя було ще 2 інші бінарні файли, згенеровані БД раніш. Я перемістив пошкоджений файл в інше місце. Потім зробив копію одного зі старих файлів, змінив його назву на таку саму як і пошкодженого файла. Також виставив відповідні права так само як у пошкодженому файлі і врешті решт скопіював його в папку де знаходяться бінарники бази.
Після цього сервер БД запустився, я авторизувався описаним вище методом і очистив бази даних. Таким чином я вирішив проблему з базою даних.