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 = 131072 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 Попытка возврата. Вы можете использовать следующую информацию, чтобы узнать где умер. Если вы не видите сообщений после этого, что-то пошло ужасно неправильно... 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 содержит информация, которая должна помочь вам выяснить, что является причиной аварии.
Любые рекомендации?
3 ответа
Уч.
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
в основном, сделайте резервную копию ваших разбитых таблиц. отредактируйте ваш /etc/my.cnf и добавьте
innodb_force_recovery = 1
чтобы увидеть, можете ли вы войти в свою базу данных и получить свои данные / найти поврежденную таблицу. Обычно, когда это происходит, это пересборка (по крайней мере, из поврежденной таблицы или двух)
с http://chepri.com/mysql-innodb-corruption-and-recovery/
- Стоп mysqld.
- Резервное копирование /var/lib/mysql/ib*
- Добавьте следующую строку в /etc/my.cnf
innodb_force_recovery = 1 (они предлагают 4, но лучше начинать с 1 и увеличивать, если он не запустится)
- Перезапустите mysqld.
- Дамп всех таблиц:# mysqldump -A > dump.sql
- Удалите все базы данных, которые нуждаются в восстановлении.
- Стоп mysqld.
- Удалить /var/lib/mysql/ib*
- Закомментируйте innodb_force_recovery в /etc/my.cnf
- Перезапустите mysqld. Посмотрите журнал ошибок MySQL. По умолчанию это должен быть /var/lib/mysql/server/hostname.com.err, чтобы увидеть, как он создает новые файлы ib *.
- Восстановите базы данных из дампа:mysql
Я столкнулся с этой же ошибкой при использовании образа 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
Я попытался добавить принудительное восстановление в конфигурацию 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 может быть повреждена, и попытаться сохранять ежедневные резервные копии и иметь документированный сценарий восстановления базы данных или закодированный в моих инструментах непрерывной интеграции.