Наш производственный сервер 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 содержит информация, которая должна помочь вам выяснить, что является причиной аварии.
Любые рекомендации?
/etc/mysql/my.cnf
или около того.Ответы:
Уч.
Проверьте предлагаемую веб-страницу: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html .
По сути, попробуйте запустить сервер MySQL в режиме восстановления и сделать резервную копию сбойных таблиц .
Отредактируйте
/etc/my.cnf
и добавьте:... чтобы узнать, сможете ли вы войти в свою базу данных и получить свои данные / найти поврежденную таблицу.
Обычно, когда это происходит, это повторная сборка (по крайней мере, поврежденной таблицы или двух).
С http://chepri.com/mysql-innodb-corruption-and-recovery/ :
mysqld
(service mysql stop
)./var/lib/mysql/ib*
Добавьте следующую строку в
/etc/my.cnf
:(они предлагают 4, но лучше всего начинать с 1 и увеличивать, если он не запустится)
Перезапустить
mysqld
(service mysql start
).mysqldump -A > dump.sql
mysqld
(service mysql stop
)./var/lib/mysql/ib*
innodb_force_recovery
в/etc/my.cnf
mysqld
. Посмотрите журнал ошибок MySQL. По умолчанию должно быть/var/lib/mysql/server/hostname.com.err
видно, как создаются новыеib*
файлы.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):
Вот некоторые ресурсы, которые вы можете попробовать, хотя ни один из вариантов восстановления не помог мне :
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
В другом окне запустите:
tail -f /var/log/mysql/error.log
Затем попробуйте перезапустить mysqld с включенными различными опциями:
sudo /etc/init.d/mysql restart
Если время истекло, вы можете принудительно перезапустить процессы mysql:
Если это работает, журнал покажет что-то вроде:
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 может быть повреждена, и попытаться сохранять ежедневные резервные копии и задокументировать сценарий восстановления базы данных или кодировать его в моих инструментах непрерывной интеграции.
источник