Не могу запустить mysql - mysql слишком быстро восстанавливается, остановлен
Сегодня я сделал свежую установку 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
Системный журнал показывает, что существует проблема со скриптом init:
[ 111]Есть идеи?
Вещи, которые я уже пробовал:
Я погуглил и нашел ошибку 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 работает, поэтому я могу продолжать то, что мне нужно сделать. Но мне нужно будет отредактировать его в какой-то момент - надеюсь, я найду решение, или на этот вопрос ответит этот момент ...
18 ответов
Я наконец понял проблему. По сути, определение некоторых параметров было удалено из предыдущей версии 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*
Миний хувьд би буруу bind-address тунхаглал. EC2-ийн хувийн IP хаягийг олж мэдэхээр ifconfig гүйж /etc/mysql/my.cnf файлд шинэчилсэн.
В моем случае я обнаружил проблему с разрешением на / tmp. Я только что установил разрешение каталога tmp на 766 и перезапустил службу mysql. Исправлено.
В моем случае проблема заключалась в / 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.
Надеюсь, это поможет ...
У меня были такие же сообщения об ошибках, но причина была другая. Мои таблицы InnoDB были повреждены, потому что вся файловая система перешла в режим только для чтения. Я исправил это повреждение, добавив следующую строку в /etc/mysql/my.cf
innodb_force_recovery = 1
Я запустил MySQL:
sudo service mysql start
MySQL действительно запустился и я выкинул/экспортировал все таблицы. Я изменил innodb_force_recovery на 0 (=default) и перезапустил MySQL:
sudo service mysql restart
I'm using Ubuntu 12.04 with MySQL 5.5. Прошло много времени, прежде чем я нашел проблему и надеюсь, что смогу помочь кому-нибудь с этим ответом. Смотрите также http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Только что обновили версию MySQL и AppArmor, как предложено здесь , чтобы решить эту проблему в Ubuntu 12.04, запущенном на экземпляре Amazon ec2. Я все еще получаю сообщение об ошибке несколько раз, но MySQL автоматически перезагружается.
После автоматического обновления до 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
Проверьте разрешения /tmp. У меня возникла эта проблема, после долгих поисков и перезагрузок я обнаружил, что разрешения /tmp были 755.
Я изменил их на 777 и mysql хорошо запустился.
Моя проблема заключалась в 0% свободного места! Дважды проверьте: -)
Fomba tsara hanalefahana ny tsy fahombiazana amin'ny fizotran'ny fanombohana ( /etc/init/mysql.conf ) dia ny manamarina ireo voina voalohany :
sudo tail -f /var/log/upstart/mysql.log
Izay no nahatonga ahy hadisoana kely:
hadisoana: 'Tsy afaka mifandray amin'ny mpizara MySQL eo an-toerana amin'ny alàlan'ny socket
Ho ahy dia vokatry ny fisian'ny mpampiasa tsy hita teo ambanin'ny vondrona [mysqld] ao amin'ny my.cnf
Для меня решением было удалить строку ...
set-variable = max_connections=200
... которая является синтаксисом MySQL 3.x и должна быть изменена на
max_connections=200
Когда у меня была аналогичная ошибка MySQL («Не удалось запустить задание») после обновления с 11.10 до 12.04, комментарий № 27 к https: //bugs.launchpad. net / ubuntu / + source / mysql-dfsg-5.1 / + bug / 573318? comments = all у меня отлично работал. Цитата:
Проблема для меня заключалась в том, что после обновления не существовало файла /etc/apparmor.d/local/usr.sbin.mysqld. Я вручную скопировал один из пустых (т.е.был только комментарий в заголовке), а потом все было хорошо.
У меня были те же проблемы, для меня адрес привязки был установлен неправильно в моем файле /etc/mysql/my.cnf . Таким образом, похоже, что все, что не так в my.cnf, может вызвать эту проблему. Я не нашел в журналах ничего, что указывало бы на это как на проблему.
Похоже, все сводится к ошибкам в конфигурации MySQL, расположенным в / etc / mysql / my.cnf и файлы в /etc/mysql/conf.d/ .
В моем случае это было неправильное значение адреса привязки , потому что IP-адрес моей машины изменился, и MySQL больше не мог связываться. Не стесняйтесь узнать больше об этом в этой статье блога .
У меня тоже была похожая проблема. Пункты ниже говорят, что они были удалены с сервера 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
У меня была аналогичная проблема. Это было неприятно, потому что я не видел журналов ошибок, указывающих, в чем проблема.
В моем случае значение, которое я установил для innodb_buffer_pool_size, было слишком большим для памяти сервера.
Я выяснил это по запуск mysqld напрямую от имени пользователя mysql.
# su mysql
# mysqld
Таким образом, вы действительно видите вывод ошибки.
Innodb имеет значение по умолчанию (innodb_buffer_pool_size), которое равно 128М - это может быть слишком большим для вашего сервера (особенно если вы используете маленький Amazon EC2 AMI - которым я был) Исправление, которое работало на меня, заключалось в добавлении следующей строки в /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
У меня была такая же проблема. Оказалось, что это репликация главного подчиненного сервера mysql my.cnf.
Проверьте свой /var/log/mysql/error.log .
Надеюсь, это немного поможет. Сначала проверьте настройки mysql, прежде чем тратить два часа на apparmor, который отлично работает.