Mysql упал и не запустится

Наш производственный сервер mysql просто вышел из строя и больше не будет работать. Это дает ошибку segfault. Я попытался перезагрузиться, и просто не знаю, что еще попробовать. Вот трассировка стека:

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 86 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Применить пакет завершен
InnoDB: запуск в фоновом режиме отката незафиксированных транзакций
140502 14:13:06 InnoDB: откат trx с идентификатором 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/en/forcing-recovery.html
InnoDB: о принудительном восстановлении.
140502 14:13:06 - mysqld получил сигнал 6;
Это может быть потому, что вы нажали ошибку. Также возможно, что этот двоичный файл
или одна из библиотек, с которыми она была связана, повреждена, неправильно построена,
или неправильно настроен. Эта ошибка также может быть вызвана неисправностью оборудования.
Мы сделаем все возможное, чтобы собрать информацию, которая, как мы надеемся, поможет диагностировать
проблема, но так как мы уже разбились, что-то определенно не так
и это может потерпеть неудачу.

key_buffer_size = 16777216
read_buffer_size = сто тридцать одна тысяча семьдесят два
max_used_connections = 0
max_threads = 151
threads_connected = 0
Возможно, что MySQL может использовать до 
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K
байты памяти
Надеюсь, что все в порядке; если нет, уменьшите некоторые переменные в уравнении.

thd: 0x0
Попытка возврата. Вы можете использовать следующую информацию, чтобы узнать
где умер mysqld Если вы не видите сообщений после этого, что-то пошло
ужасно неправильно ...
stack_bottom = (ноль) thread_stack 0x30000
140502 14:13:06 [Примечание] Планировщик событий: загружено 0 событий
140502 14:13:06 [Замечание] / usr / sbin / mysqld: готов к подключению.
Версия: сокет '5.1.41-3ubuntu12.10': порт /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/en/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/en/forcing-recovery.html .

По сути, попробуйте запустить сервер MySQL в режиме восстановления и сделать резервную копию сбойных таблиц .

Отредактируйте /etc/my.cnfи добавьте:

 innodb_force_recovery = 1

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

Обычно, когда это происходит, это повторная сборка (по крайней мере, поврежденной таблицы или двух).

С http://chepri.com/mysql-innodb-corruption-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

Я столкнулся с этой же ошибкой при использовании образа Docker mysql: 5.7. Основной ошибкой была попытка создать пользователя root, который существует по умолчанию. Дополнительная информация: https://github.com/docker-library/mysql/issues/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/en/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-corruption-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 может быть повреждена, и попытаться сохранять ежедневные резервные копии и задокументировать сценарий восстановления базы данных или кодировать его в моих инструментах непрерывной интеграции.