Centos: еще один демон MySQL уже работает с одним и тем же гнездом unix

Ответ 1

Чтобы предотвратить возникновение проблемы, вы должны выполнить изящное завершение работы сервера из командной строки, а не отключать сервер.

# shutdown -h now

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

Основываясь на Centos, дополнительный метод для его восстановления снова при запуске этой проблемы заключается в перемещении mysql.sock:

# mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak

# service mysqld start

Перезапуск службы создает новую запись с именем mqsql.sock

Ответ 2

TL; DR:

Запустите это как root, и все будет установлено:

rm $(grep socket /etc/my.cnf | cut -d= -f2)  && service mysqld start

Более длинная версия:

Вы можете найти местоположение файла сокета MySQL, вручную высунув его в /etc/my.conf или просто используя

grep socket /etc/my.cnf | cut -d= -f2

Вероятно, это будет /var/lib/mysql/mysql.sock. Затем (как root, конечно, или с sudo preended) удалите этот файл:

rm /var/lib/mysql/mysql.sock

Затем запустите демон MySQL:

service mysqld start

Удаление mysqld не решит проблему вообще. Проблема в том, что CentOS и RedHat не очищают файл sock после сбоя, поэтому вам нужно сделать это самостоятельно. Избегание выключения вашей системы (конечно) также рекомендуется, но иногда вы не можете избежать этого, поэтому эта процедура решит проблему.

Ответ 3

Я нашел решение для всех в этой проблеме измените директорию сокета на новое место в файле my.cnf

socket=/var/lib/mysql/mysql2.sock

и service mysqld start

или быстрый способ, как ответил GeckoSEO

# mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak

# service mysqld start

Ответ 4

Мое решение для этого было оставлено над mysql.sock в каталоге/var/lib/mysql/из жесткого отключения. Mysql думал, что он уже работает, когда он не работает.

Ответ 5

Просто откройте отчет об ошибке, когда поставщик ОС попросит их поместить сокет в /var/run, чтобы он автоматически удалялся при перезагрузке. Это ошибка для сохранения этого сокета после нечистой перезагрузки, /var/run - это место для этих файлов.

Ответ 6

чтобы автоматически очистить файл .sock, поместите эти строки в файл /etc/init.d/mysqld сразу после "start" ) блок кода

test -e /var/lib/mysql/mysql.sock
SOCKEXIST=$?

ps cax | grep mysqld_safe
NOPIDMYSQL=$?

echo NOPIDMYSQL $NOPIDMYSQL
echo SOCKEXIST $SOCKEXIST

if [ $NOPIDMYSQL -eq 1 ] && [ $SOCKEXIST -eq 0 ] ; then
    echo "NOT CLEAN"
    rm -f /var/lib/mysql/mysql.sock
    echo "FILE SOCK REMOVED"
else
    echo "CLEAN"
fi

это сработало для меня. Я должен был это сделать, потому что у меня нет ИБП, и часто у нас есть сбои питания.

С уважением.

Ответ 7

Может случиться, что когда служба MySQL не отключится должным образом во время перезагрузки ОС. Осталось /var/lib/mysql/mysql.sock. Это предотвращает запуск mysqld.

Эти шаги могут помочь:

1: запуск службы mysqld killall -9 mysqld_safe mysqld служба mysqld start

2: rm/var/lib/mysql/mysql.sock  служба mysqld start

Ответ 8

Чтобы запустить службу MySQL, вы можете удалить '/var/lib/mysql/mysql.sock' и снова запустить службу MySQL:

Удалите файл сокета:

[[email protected] ~]# rm /var/lib/mysql/mysql.sock
rm: remove socket `/var/lib/mysql/mysql.sock'? yes

Запустите службу MySQL:

[[email protected]~]# service mysqld start
Starting mysqld:                                           [  OK  ]

Это поможет вам решить вашу проблему.

Ответ 9

Это просто происходит из-за аномального завершения службы mysql. удалите или сделайте резервную копию файла /var/lib/mysql/mysql.sock и перезапустите mysql.

Пожалуйста, дайте мне знать, если в случае каких-либо проблем..

Ответ 10

Я только что прошел через эту проблему, и ни одна из предложений не решила мою проблему. В то время как я не смог запустить MySQL при загрузке и нашел одно и то же сообщение в журналах ( "Еще один демон MySQL уже работает с одним и тем же unix-сокетом" ), я смог запустить службу, когда я пришел в консоль.

В моем файле конфигурации я нашел следующую строку: bind-address=xx.x.x.x. Я случайно решил прокомментировать это, и ошибка при загрузке исчезла. Поскольку адрес привязки обеспечивает безопасность, я решил изучить его дальше. Я использовал IP-адрес машины, а не адрес обратной связи IPv4 - 127.0.0.1.

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