Mysql вийшов з ладу і не запуститься

Наш сервер виробництва mysql просто вийшов з ладу і не повернеться. Це дає помилку сегментації. Я спробував перезавантаження, і просто не знаю, що ще спробувати. Ось стек-трек:

140502 14:13:05 [Примітка] Плагін "FEDERATED" вимкнено.
InnoDB: Сканування журналу пройшло повз контрольну точку lsn 108 1057948207
140502 14:13:06 InnoDB: База даних не працювала нормально!
InnoDB: Початок відновлення аварійних ситуацій.
InnoDB: Читання інформації про простір таблиць з файлів .ibd ...
InnoDB: Відновлення можливих напівзаписаних сторінок даних із подвійного написання
InnoDB: буфер ...
InnoDB: Виконується відновлення: сканується до послідовності журналу 108 1058059648
InnoDB: 1 транзакція (и), яку потрібно скасувати або очистити
InnoDB: всього 15 рядкових операцій для скасування
InnoDB: Лічильник ідентифікатора Trx становить 0 562485504
140502 14:13:06 InnoDB: Запуск застосувати партію записів журналів до бази даних ...
InnoDB: Прогрес у відсотках: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Застосування партії завершено
InnoDB: Починаючи з фонового режиму відкат неподаних транзакцій
140502 14:13:06 InnoDB: Відкат trx з id 0 562485192, 15 рядків для скасування
140502 14:13:06 InnoDB: розпочато; порядковий номер журналу 108 1058059648
140502 14:13:06 InnoDB: Невдача ствердження в потоці 1873206128 у файлі ../../../storage/innobase/fsp/fsp0fsp.c рядок 1593
InnoDB: Невдале твердження: frag_n_used> 0
InnoDB: Ми навмисно генеруємо пастку пам’яті.
InnoDB: Надішліть детальний звіт про помилку на http://bugs.mysql.com.
InnoDB: Якщо ви отримуєте неодноразові збої або збої, навіть
InnoDB: одразу після запуску mysqld можливо
InnoDB: пошкодження у просторі таблиць InnoDB. Будь ласка зверніться до
InnoDB: http://dev.mysql.com/doc/refman/5.1/uk/forcing-recovery.html
InnoDB: про примушення відновлення.
140502 14:13:06 - mysqld отримав сигнал 6;
Це може бути тому, що ви потрапили на помилку. Можливо також, що цей двійковий
або одна з бібліотек, з якою вона була пов’язана, є пошкодженою, неправильно побудованою,
або неправильно налаштований. Ця помилка також може бути викликана несправністю апаратного забезпечення.
Ми спробуємо зробити все можливе, щоб підкреслити інформацію, яка, сподіваємось, допоможе поставити діагноз
проблема, але оскільки ми вже зазнали аварій, щось точно не так
і це може не вдатися.

key_buffer_size = 16777216
read_buffer_size = 131072
max_used_connections = 0
max_threads = 151
thread_connected = 0
Можливо, що mysqld міг би використовувати до 
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K
байти пам'яті
Сподіваюся, що це нормально; якщо ні, зменшіть деякі змінні рівняння.

thd: 0x0
Спроба відступити. Ви можете використовувати таку інформацію, щоб дізнатися це
де помер Myqld. Якщо після цього ви не бачите жодних повідомлень, щось пішло
страшенно неправильно ...
stack_bottom = (нульова) thread_stack 0x30000
140502 14:13:06 [Примітка] Планувальник подій: Завантажено 0 подій
140502 14:13:06 [Примітка] / usr / sbin / mysqld: готовий до з'єднань.
Версія: '5.1.41-3ubuntu12.10' socket: '/var/run/mysqld/mysqld.sock' порт: 3306 (Ubuntu)
/ usr / sbin / mysqld (my_print_stacktrace + 0x2d) [0xb7579cbd]
/ usr / sbin / mysqld (handle_segfault + 0x494) [0xb7245854]
[0xb6fc0400]
/lib/tls/i686/cmov/libc.so.6(abort+0x182) [0xb6cc5a82]
/ usr / sbin / mysqld (+ 0x4867e9) [0xb74647e9]
/ usr / sbin / mysqld (btr_page_free_low + 0x122) [0xb74f1622]
/ usr / sbin / mysqld (btr_compress + 0x684) [0xb74f4ca4]
/ usr / sbin / mysqld (btr_cur_compress_if_useful + 0xe7) [0xb74284e7]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72]
/ usr / sbin / mysqld (btr_node_ptr_delete + 0x82) [0xb74f4012]
/ usr / sbin / mysqld (btr_discard_page + 0x175) [0xb74f41e5]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28]
/ usr / sbin / mysqld (+ 0x526197) [0xb7504197]
/ usr / sbin / mysqld (row_undo_ins + 0x1b1) [0xb7504771]
/ usr / sbin / mysqld (row_undo_step + 0x25f) [0xb74c210f]
/ usr / sbin / mysqld (que_run_threads + 0x58a) [0xb74a31da]
/ usr / sbin / mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0xb6f9f96e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb6d65a4e]
Сторінка керівництва на веб-сайті http://dev.mysql.com/doc/mysql/uk/crashing.html містить
інформація, яка повинна допомогти вам з’ясувати, що викликає збій.

Будь-які рекомендації?

Ой.

InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

Перегляньте запропоновану веб-сторінку: http://dev.mysql.com/doc/refman/5.1/uk/forcing-recovery.html .

В основному спробуйте запустити MySQL-сервер у режимі відновлення та зробити резервну копію ваших таблиць, що розбилися .

Відредагуйте свій /etc/my.cnfі додайте:

 innodb_force_recovery = 1

... щоб побачити, чи можете ви потрапити у вашу базу даних та отримати свої дані / знайти зіпсовану таблицю.

Зазвичай, коли це відбувається, це відбудова (принаймні зіпсованої таблиці або двох).

З http://chepri.com/mysql-innodb-corrup-and-recovery/ :

1. Зупинка mysqld(service mysql stop ).
2. Резервне копіювання /var/lib/mysql/ib*

3. Додайте наступний рядок до /etc/my.cnf:

   innodb_force_recovery = 1
   

   (вони пропонують 4, але найкраще починати з 1 і приросту, якщо він не почнеться)

4. Перезапустити mysqld(service mysql start ).

5. Вивантажте всі таблиці: mysqldump -A > dump.sql
6. Відкиньте всі бази даних, які потребують відновлення.
7. Зупинка mysqld(service mysql stop ).
8. Видалити /var/lib/mysql/ib*
9. Коментуйте innodb_force_recovery в/etc/my.cnf
10. Перезапустити mysqld. Подивіться на журнал помилок mysql. За замовчуванням слід /var/lib/mysql/server/hostname.com.errпобачити, як це створює новеib* файли.
11. Відновлення баз даних з дампа: mysql < dump.sql

Я зіткнувся з цією ж помилкою під час використання докерського зображення mysql: 5.7. Основна помилка була спроба створити root користувача, який існує за замовчуванням. Більше інформації: https://github.com/docker-library/mysql/isissue/129

Як зазначено у вищенаведеному посиланні, під час запуску докерного зображення рішенням було НЕ встановлювати MYSQL_USER та MYSQL_PASSWORD у змінні середовища.

Це сталося зі мною в Laravel Homestead (Vagrant після паніки ядра під керуванням Mac OS Sierra 10.12.4 (16E195):

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper

Ось деякі ресурси, які можна спробувати, хоча жоден із варіантів ремонту не працював для мене :

https://dev.mysql.com/doc/refman/5.7/uk/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corrup-cases-for-the-MySQL-database

Я спробував додати відновлення примусу до конфігурації mysql (почніть з 1 і зростайте поступово вище, оскільки нібито більші числа можуть спричинити постійну пошкодження):

sudo nano /etc/mysql/my.cnf

[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled

В іншому вікні запустіть:

tail -f /var/log/mysql/error.log

Потім спробуйте перезапустити mysqld з увімкненими різними параметрами:

sudo /etc/init.d/mysql restart

Якщо час вичерпано, ви можете змусити перезапустити mysql процеси за допомогою:

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
sudo kill -9 <process-id>
sudo /etc/init.d/mysql restart

Якщо він працює, журнал покаже щось на зразок:

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

Якщо це не вдалося, журнал покаже щось на зразок:

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420

Коли гірше стало гірше, я спробував видалити бази даних, які можуть бути пошкодженими:

sudo ls -alt /var/lib/mysql

Виявилося, що база даних, над якою я працював, була нещодавно зміненою вгорі списку. На щастя, у мене був цей дамп для SQL з того дня, тому вдалося його видалити:

sudo rm -rf /var/lib/mysql/<database_name>

Я залишив усі інші файли, і mysql вдалося все-таки запустити.

ОНОВЛЕННЯ: не забудьте вимкнути, innodb_force_recovery = 1коли mysql знову працює, інакше ви отримаєте помилки при спробі зміни баз даних та таблиць.

Потім я відтворив базу даних із Sequel Pro, знову імпортував свої дані і зміг рухатись далі, не викидаючи всіх баз даних з інших моїх проектів.

Ідучи вперед, я повинен припустити, що будь-яка база даних mysql може бути пошкоджена, і спробувати підтримувати щоденні резервні копії та задокументувати або зашифрувати сценарій відтворення бази даних в моїх інструментах постійної інтеграції.