Не удается запустить mysql - mysql respawning слишком быстро, остановлено

Сегодня я сделал новую установку ubuntu 12.04 и занялся настройкой моей локальной среды разработки. Я установил mysql и отредактировал /etc/mysql/my.cnf, чтобы оптимизировать InnoDB, но когда я пытаюсь перезапустить mysql, он выходит из строя с ошибкой:

[20:53][tom@Pochama:/var/www/website] (master) $ sudo service mysql restart
start: Job failed to start

В syslog обнаружена проблема с скриптом инициализации: [!d1 ]

> tail -f /var/log/syslog

Apr 28 21:17:46 Pochama kernel: [11840.884524] type=1400 audit(1335644266.033:184): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=760 comm="apparmor_parser"
Apr 28 21:17:47 Pochama kernel: [11842.603773] init: mysql main process (764) terminated with status 7
Apr 28 21:17:47 Pochama kernel: [11842.603841] init: mysql main process ended, respawning
Apr 28 21:17:48 Pochama kernel: [11842.932462] init: mysql post-start process (765) terminated with status 1
Apr 28 21:17:48 Pochama kernel: [11842.950393] type=1400 audit(1335644268.101:185): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=811 comm="apparmor_parser"
Apr 28 21:17:49 Pochama kernel: [11844.656598] init: mysql main process (815) terminated with status 7
Apr 28 21:17:49 Pochama kernel: [11844.656665] init: mysql main process ended, respawning
Apr 28 21:17:50 Pochama kernel: [11845.004435] init: mysql post-start process (816) terminated with status 1
Apr 28 21:17:50 Pochama kernel: [11845.021777] type=1400 audit(1335644270.173:186): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=865 comm="apparmor_parser"
Apr 28 21:17:51 Pochama kernel: [11846.721982] init: mysql main process (871) terminated with status 7
Apr 28 21:17:51 Pochama kernel: [11846.722001] init: mysql respawning too fast, stopped

Любые идеи?

Вещи, которые я уже пробовал:

Я googled и нашел ошибку Ubuntu с apparmor (https: // bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/970366), я изменил apparmor из режима принуждения в режим подачи жалоб:

sudo apt-get install apparmor-utils
sudo aa-complain /usr/sbin/mysqld
sudo /etc/init.d/apparmor reload

, но это не помогло. Я все еще не могу запустить mysql.

Я также думал, что проблема может быть в том, что лог-файлы InnoDB были другого размера, чем ожидал mysql. Я удалил файлы журнала innodb перед перезагрузкой, используя: sudo mv /var/lib/mysql/ib_logfile* /tmp.

Обходной путь: я повторно установил 12.04, поэтому не прикасался к /etc/mysql/my.cnf. Mysql работает, поэтому я могу заняться тем, что мне нужно. Но мне нужно будет отредактировать его в какой-то момент. Надеюсь, я выясню решение, или на этот вопрос будет дан ответ на этот вопрос ...

1
задан Jorge Castro 2 October 2012 в 13:25
поделиться

18 ответов

У Innodb установлен параметр по умолчанию (innodb_buffer_pool_size), который установлен на 128M - это может быть слишком большим для вашего сервера (особенно если вы используете небольшой AMI AMAZON EC2, который я был). Исправление, которое сработало для меня, было добавьте следующую строку в /etc/mysql/my.cnf

innodb_buffer_pool_size = 16M

Я написал об этом исправлении здесь http://www.mlynn.org/2012/07/mysql-5-5-on-ubuntu-12 -04-работа-не удалось-начало

10
ответ дан Mike Lynn 25 May 2018 в 09:13
поделиться
  • 1
    Оказывается, моя виртуальная машина была просто исчерпана. Установка innodb_buffer_pool_size ниже была одной из частей решения, но будьте осторожны, вы можете просто потерять память. – thaddeusmt 8 January 2015 в 18:47

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

В моем случае значение, которое я установил для innodb_buffer_pool_size, было слишком большим для памяти сервера.

Я нашел это, запустив mysqld непосредственно в качестве пользователя mysql.

# su mysql
# mysqld

Таким образом вы действительно видите вывод ошибки.

10
ответ дан Joel 25 May 2018 в 09:13
поделиться
  • 1
    Это отличный совет, я изо всех сил пытался получить какую-то значимую отладочную информацию из mysql. Благодаря! – niallsco 23 May 2013 в 20:29

У меня также была аналогичная проблема. В приведенных ниже пунктах говорится, что они были удалены с сервера mysql 5.5. Если у вас их в my.cnf, он не запустится. Прокомментируйте их с помощью #. (Информация получена из: http://dev.mysql.com/doc/refman/5.5/en/replication-options-slave.html)

В этом списке показаны следующие параметры: [!d4 ]

 --master-host
 --master-user
 --master-password
 --master-port
 --master-connect-retry
 --master-ssl
 --master-ssl-ca
 --master-ssl-capath
 --master-ssl-cert
 --master-ssl-cipher
 --master-ssl-key
3
ответ дан belacqua 25 May 2018 в 09:13
поделиться
  • 1
    Отлично! Именно то, что меня выбрасывало. Благодарю. – Brad F Jacobs 26 March 2013 в 00:25

Кажется, сводится к ошибкам в конфигурации MySQL, расположенной в /etc/mysql/my.cnf и файлах в /etc/mysql/conf.d/.

В моем случае это было неправильное значение bind-address, поскольку IP-адрес моей машины, и MySQL больше не мог связываться. Не стесняйтесь рассказывать об этом в этой статье в блоге.

3
ответ дан gertvdijk 25 May 2018 в 09:13
поделиться

Хороший способ отладки сбоев в процессе после старта (/etc/init/mysql.conf) - проверить журналы выскочки:

sudo tail -f /var/log/upstart/mysql.log 

Это дало мне ошибку сокета:

: «Не удается подключиться к локальному серверу MySQL через сокет

. В моем случае это было вызвано отсутствием параметра user в группе [mysqld] в my.cnf

2
ответ дан prusswan 25 May 2018 в 09:13
поделиться

Когда у меня была аналогичная ошибка MySQL («Запуск не удалось запустить») после обновления с 11.10 по 12.04, комментарий № 27 на https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/ + bug / 573318? comments = все отлично работало для меня. Цитата:

Проблема для меня заключалась в том, что файл /etc/apparmor.d/local/usr.sbin.mysqld не существовал после обновления. Я вручную скопировал один из одного из пустых (т. Е. Имел только комментарий заголовка), и тогда все было хорошо.
1
ответ дан marcvangend 25 May 2018 в 09:13
поделиться

Для меня решение было удалить строку ...

set-variable = max_connections=200

... которая является синтаксисом MySQL 3.x и должна быть изменена на

max_connections=200
1
ответ дан Jorge Castro 25 May 2018 в 09:13
поделиться

У меня была такая же проблема. Это оказалось mysql my.cnf master slave replications. Проверьте /var/log/mysql/error.log.

Надеюсь, это немного поможет. Сначала проверьте настройки mysql, прежде чем потратить два часа на работу с помощью apparmor, который просто отлично работает.

1
ответ дан Eliah Kagan 25 May 2018 в 09:13
поделиться

У меня были те же проблемы, для меня bind-address был установлен неправильно в моем файле /etc/mysql/my.cnf. Таким образом, кажется, что что-то, что не подходит в my.cnf, может вызвать эту проблему. Я не нашел ничего в журналах, которые указали это как проблему.

1
ответ дан Chris 25 May 2018 в 09:13
поделиться

Моя проблема была 0% свободного места! Двойная проверка: -)

1
ответ дан moamahi 25 May 2018 в 09:13
поделиться

Проверьте разрешения /tmp. У меня была эта проблема, после многого времени googleing и перезагрузки, я узнал, что разрешения /tmp были 755.

Я меняю его на 777, а mysql начинает хорошо.

1
ответ дан shgnInc 25 May 2018 в 09:13
поделиться
  • 1
    эта вещь в древности, но это была моя проблема ... не знаю, как это изменилось ... – TheHidden 23 October 2015 в 10:13
  • 2
    в некоторых случаях, путем изменения файловой системы или установки /tmp в новом разделе. – shgnInc 25 October 2015 в 05:44

После автоматического обновления до mysqld-5.5.53 ubuntu 14.04.1 mysql не запускался. Эти строки появились в моем syslog:

Oct 27 06:05:51 hostname kernel: [  593.168925] init: mysql post-start process (4997) terminated with status 1
Oct 27 06:05:51 hostname kernel: [  593.178241] type=1400 audit(1477562751.231:31): apparmor="STATUS" operation="profile_replace" profile="unconfined" name
Oct 27 06:05:51 hostname kernel: [  593.204392] init: mysql main process (5032) terminated with status 1
Oct 27 06:05:51 hostname kernel: [  593.204404] init: mysql respawning too fast, stopped

Проблема была решена путем создания этого каталога:

sudo mkdir /var/lib/mysql-files
sudo chmod 700 /var/lib/mysql-files
sudo chown mysql:mysql /var/lib/mysql-files
sudo /etc/init.d/mysql start
1
ответ дан Yapsr 25 May 2018 в 09:13
поделиться

Просто обновленная версия MySQL и AppArmor, как предлагается здесь, чтобы устранить эту проблему на Ubuntu 12.04, запущенной на экземпляре Amazon ec2. Я все еще получаю ошибку несколько раз, но MySQL перезагружается автоматически.

0
ответ дан Kazark 25 May 2018 в 09:13
поделиться

У меня были те же сообщения об ошибках, но причина была другая. Мои таблицы InnoDB были повреждены, потому что вся файловая система перешла в режим только для чтения. Я исправил коррупцию, добавив следующую строку в /etc/mysql/my.cf

innodb_force_recovery = 1

Я запустил MySQL:

sudo service mysql start

MySQL запустился, и я сбросил / экспортировал все таблицы. Я изменил innodb_force_recovery на 0 (= по умолчанию) и перезапустил MySQL:

sudo service mysql restart

Я использую Ubuntu 12.04 с MySQL 5.5. Мне потребовалось много времени, прежде чем я нашел проблему, и надеюсь, что смогу помочь кому-то с этим ответом. См. Также http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

0
ответ дан Coanda 25 May 2018 в 09:13
поделиться

В моем случае проблема заключалась в разрешении файла /etc/mysql/my.cnf.

Я изменил его для удобства, но он вызвал erros, как

kernel: [604528.290448] type=1400 audit(1424350956.727:193): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/mysqld" pid=15008 comm="apparmor_parser"

Разрешение my.cnf составило 766 и я изменил его на 744, и две из трех ошибок исчезли. Существует еще одно подобное сообщение об ошибке, но оно не предотвратило запуск mysql.

Надеюсь, это поможет ...

0
ответ дан Marcelo_nnn 25 May 2018 в 09:13
поделиться

В моем случае у меня было неправильное объявление bind-address. Я запустил ifconfig, чтобы открыть частный IP-адрес EC2 и обновил его в файле /etc/mysql/my.cnf.

0
ответ дан n3rve 25 May 2018 в 09:13
поделиться

В моем случае я нашел проблему разрешения на / tmp. Я только установил разрешение на каталог tmp на 766 и перезапустил службу mysql. Исправлено.

0
ответ дан Fernando Luis Barbosa 25 May 2018 в 09:13
поделиться
Другие вопросы по тегам: