MySQL: увеличен буферный пул, ibdata1 поврежден?

Я пытался увеличить innodb_buffer_pool_size с помощью my.cnf от 128 до 256 м по умолчанию, но при попытке перезапуска завершение работы mysql завершилось неудачно с:

130125 11:49:55 InnoDB: Initializing buffer pool, size = 256.0M
130125 11:49:55 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11

MySQL запущен и работает, но любая попытка "mysql -u root -p" через терминал проваливается:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)

Я касаюсь mysql.sock и chown'd в соответствующих местах (поскольку они отсутствовали, не очень хорошо), но все равно не везет в mysql.

Имейте дамп с прошлой ночи, но хотелось бы получить дамп с сегодняшнего дня, чтобы увидеть, не поврежден ли ibdata1 (операции чтения / записи выглядят нормально, поэтому, если он был поврежден, mysql завершит работу, нет?)

Излишне говорить, беспокоюсь о попытке перезагрузки! У нас есть приложение Java, которое подключается к MySQL через пул соединений; там происходит блокировка?

Во всяком случае, идеи о том, как подойти к ситуации, приветствуются. Возможно, клонировать виртуальную машину MySQL, на которой выполняется запуск, и импортировать каталог /var/lib/mysql, чтобы увидеть, что происходит, но если это просто вопрос воссоздания файлов sock и pid и перезапуска, нет смысла тратить впустую день.

Источник

2 ответа

Решение

Что-то еще удерживает блокировку файла на ibdata1. использование lsof на ibdata1 и выясните, кто держит замок.

Источник

Получив это, файлы mysql.sock и mysql.pid оказались в состоянии самоволки, поэтому я:

touch /var/lib/mysql/mysql.sock
chown mysql.mysql /var/lib/mysql/mysql.sock
touch /var/run/mysqld/mysqld.pid
chown mysql.mysql /var/run/mysqld/mysqld.pid
echo [pid of running mysqld] > /var/run/mysqld/mysqld.pid

Служба mysqld была запущена, поэтому с клиентским сайтом все было в порядке, но, учитывая тревожные ошибки в журнале, у меня сложилось впечатление, что файл ibdata был поврежден: "Не удалось открыть или создать файлы данных...InnoDB записывал только те файлы, которые были заполнены нулями", но еще не использовал их. Но будьте осторожны, не удаляйте старые файлы данных, которые содержат ваши ценные данные!"

Я имею в виду, трудно не думать, что небо падает, учитывая громоздкие предупреждения и ошибки - похоже, что дерьмо попало в вентилятор, когда, в данном случае, его совсем нет.

Запустил выше через терминальную сессию с последующим service mysql restart и вуаля, все еще работающая с размером пула буферов, увеличенным до 256 МБ, как я изначально планировал, когда внес изменения в my.cnf этим утром.

Что касается причины проблемы, я побежал mysqltuner.pl проверить узкие места производительности; это должно создать новый процесс mysqld в дополнение к запущенному процессу mysqld, который остается подключенным после выполнения скрипта (во время сбоя перезапуска grep'а было 4 процесса mysqld 2 для корневого mysqld_safe и 2 для mysql mysqld).

Уничтожение созданного процесса mysqltuner.pl не решило проблему, так как файлы mysql.sock и mysql.pid ушли с ним, а затем я не смог войти в клиент mysql. Заглядывая в бревна, я боялся худшего и провел пару часов, прочесывая сеть.

Много шума из ничего;-)

Источник
Другие вопросы по тегам