Я пробовал увеличить 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 и mysqld.pid в соответствующих местах (так как они отсутствовали, не очень хорошо), но мне все равно не удалось попасть в mysql.
Есть дамп с прошлой ночи, но хотелось бы получить дамп с сегодняшнего дня, чтобы увидеть, не поврежден ли ibdata1 (операции чтения / записи кажутся нормальными, поэтому, если он был поврежден, mysql отключится, нет?)
Излишне говорить, что беспокоит попытка перезапуска! У нас есть приложение Java, которое подключается к MySQL через пул соединений; там происходит блокировка?
Во всяком случае, идеи о том, как подойти к ситуации, были оценены. Можно клонировать виртуальную машину, на которой работает MySQL, и импортировать каталог / var / lib / mysql, чтобы увидеть, что происходит, но если это просто вопрос воссоздания файлов sock и pid и выполнения перезапуска, нет смысла тратить полдня.
Что-то еще удерживает блокировку файла на 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'ing во время неудачного перезапуска было 4 процесса mysqld: 2 для root mysqld_safe и 2 для mysql mysqld).
Удаление созданного процесса mysqltuner.pl не решило проблему, так как файлы mysql.sock и mysql.pid пошли вместе с ним, а затем я не смог войти в клиент mysql. Заглянув в бревна, я опасался худшего и пару часов рылся в сети.
Много шума из ничего ;-)