Вопрос: Mysql разбился и не запускался


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

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 id равен 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/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
Возможно, mysqld может использовать до
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K
байт памяти
Надеюсь, все в порядке; если нет, уменьшите некоторые переменные в уравнении.

thd: 0x0
Попытка возврата. Вы можете использовать следующую информацию, чтобы узнать
где mysqld умер. Если после этого вы не увидите сообщений, что-то пошло
ужасно неправильно ...
stack_bottom = (nil) 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/en/crashing.html содержится
информацию, которая должна помочь вам узнать, что вызывает крушение.

Любые рекомендации?


11
2018-05-02 19:20


Источник


Первые вещи сначала; кто-то изменил конфигурацию MySQL каким-то образом? См. Последнюю дату изменения для /etc/mysql/my.cnf или так. - Janne Pikkarainen
Нет. Чтобы завершить mysqldump, нужно установить innodb_force_recovery = 3, а затем сбросить и прочитать БД. Это фиксировало это. - tilleryj


Ответы:


Уч.

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/

  1. Остановить mysqld.
  2. Резервное копирование / var / lib / mysql / ib *
  3. Добавьте следующую строку в /etc/my.cnf

innodb_force_recovery = 1 (они предлагают 4, но лучше всего начинать с 1 и увеличивать, если он не запустится)

  1. Перезагрузите mysqld.
  2. Дамп всех таблиц: # mysqldump -A> dump.sql
  3. Отбросьте все базы данных, требующие восстановления.
  4. Остановить mysqld.
  5. Удалить / var / lib / mysql / ib *
  6. Комментарий out innbb_force_recovery в /etc/my.cnf
  7. Перезагрузите mysqld. Посмотрите журнал ошибок mysql. По умолчанию он должен быть /var/lib/mysql/server/hostname.com.err, чтобы узнать, как он создает новые файлы ib *.
  8. Восстановить базы данных из дампа: mysql <dump.sql

20
2018-05-02 19:29



Я бы сначала подумал, что у вас может быть повреждение файловой системы или плохой диск. - bombcar
попробуйте все значения innodb_force_recovery до 6. И добавьте innodb_purge_threads = 0 - иногда главный поток не может запускаться, вы увидите его в журнале ошибок - akuzminsky
Я знаю, что это старый поток, но какая-либо разработка по определению того, какие базы данных нуждаются в восстановлении? - nicolekanderson
@nicolekanderson Мне также хотелось бы получить некоторые разъяснения по этому вопросу. После запуска mysqldump это никоим образом не указывает на то, что любая из баз данных повреждена. - Andrew Thaddeus Martin
точка 10 в ответе - попробуйте перезапустить сервер базы данных и прочитать журнал ошибок, он должен указать имя разбитых таблиц. mysqldump только дает вам копию таблиц, ничего не делает. - Jonathan


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

Как указано в приведенной выше ссылке, решение заключалось в том, чтобы НЕ устанавливать MYSQL_USER и MYSQL_PASSWORD в переменных среды при запуске образа докеров.


2
2018-05-27 05:35





Это случилось со мной в Laravel Homestead (бродяга после паники ядра под управлением 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 может быть повреждена и попытаться сохранить ежедневные резервные копии и создать сценарий для восстановления базы данных, документированный или закодированный в мои инструменты непрерывной интеграции.


1
2018-06-15 02:04