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


33

Сегодня я сделал новую установку 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

Системный журнал показывает, что есть проблема со сценарием инициализации:

> 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

Любые идеи?


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

Я погуглил и нашел ошибку 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. Не повезло, хотя.

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

Ответы:


29

Я наконец понял проблему. По сути, определение некоторых параметров было удалено из предыдущей версии mysql и заменено другими именами. Чтобы исправить, в /etc/mysql/my.cnf замените:

# Tom Added to ensure the server character set is set to utf8
default-character-set = utf8
default-collation     = utf8_general_ci

с:

# Tom Added to ensure the server character set is set to utf8
character_set_server  = utf8
collation_server      = utf8_general_ci

Это связанный отчет об ошибке панели запуска: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/958120 .

Или легко запустить:

# Miraz added dpkg-reconfigure
dpkg-reconfigure mysql-server-5.5

Но убедитесь, что не установлена ​​старая версия mysql, если она есть, удалите:

# Miraz quick mysql package check
dpkg -l *mysql*

У меня не было этой проблемы, но dpkg-reconfigure mysql-server-5.5все исправлено в моей конфигурации.
Дэвид Пердью

в моем случае проблема заключалась в неправильном имени свойства в /etc/mysql/my.cnf.... из этого блога: dangtrinh.com/2014/05/… , запустите mysqld -v. Я попытался погуглить MySQL код выхода 7, но безуспешно. Я предполагаю, что код выхода 7 связан с ошибками при разборе файла конфигурации mysql.
MaasSql

У меня была такая же проблема, но мне было трудно ее отследить, потому что моя неверная конфигурация находилась в /etc/mysql/conf.d/*, а также потому, что были старые журналы с именем /var/log/mysql.*, из-за которых я не замечал активные журналы / var / log / mysql / *.
Дейв Берт

1
примечание стороны: utf8_unicode_ciлучше. Теперь дажеutf8mb4_unicode_ci
Акшай

10

У 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-job-failed-to-start


Оказывается, моей виртуальной машине просто не хватило памяти. Установка innodb_buffer_pool_sizeниже была одной из частей решения, но будьте осторожны, возможно, вам просто не хватает памяти.
thaddeusmt

10

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

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

Я выяснил это, запустив mysqld напрямую как пользователь mysql.

# su mysql
# mysqld

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


2
Это отличный совет, я изо всех сил пытался получить какую-то значимую отладочную информацию из mysql. Благодарность!
eageranalyst

3

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

Затронутые параметры показаны в этом списке:

 --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

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

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


2

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

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

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

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

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


1

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

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


1

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

set-variable = max_connections=200

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

max_connections=200

1

Я была такая же проблема. Оказалось, что это репликация master-slave mysql my.cnf. Проверьте свой /var/log/mysql/error.log.

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


1

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


1

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


1

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

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


эта вещь в древности, но это была моя проблема .... не знаю, как это изменилось ...
TheHidden

в некоторых случаях путем изменения файловой системы или монтирования /tmpна новый раздел.
ShgnInc

1

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

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

0

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


1
Добро пожаловать в Спросите Ubuntu! Хотя это может теоретически ответить на вопрос, было бы предпочтительным включить здесь основные части ответа и предоставить ссылку для справки.
Ringtail

0

У меня были те же сообщения об ошибках, но причина была в другом. Мои таблицы 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

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

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

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

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


0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.