MySQL не может соединиться через “localhost”, только 127.0.0.1

ip addr поскольку корень является способом пойти.

27
задан 3 August 2011 в 23:13
11 ответов

MySQL попытается соединиться с сокетом Unix, если Вы скажете ему соединяться с "localhost". Если Вы говорите этому соединяться с 127.0.0.1, что Вы вынуждаете это соединиться с сетевым сокетом. Так, вероятно, Вам настроили MySQL, чтобы только слушать сетевой сокет а не к сокету файловой системы.

То, что точно является неправильным с Вашим сокетом Unix, трудно сказать. Но я рекомендую Вам прочитать эту страницу на справочнике MySQL. Это должно помочь Вам.

ОБНОВЛЕНИЕ: На основе обновленного вопроса: параметр "сокет" должен быть чем-то вроде этого: "/var/lib/mysql/mysql.sock". Эта страница в Справочнике имеет еще некоторую информацию.

Здесь у Вас есть начало моего/etc/my.cnf файла:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

Ваш файл должен быть подобным. Затем Ваша проблема должна быть решена. Не забывайте перезапускать сервер MySQL перед тестированием его.

26
ответ дан 28 November 2019 в 20:05

Можно было включить IPv6, его очень возможный localhost решает к ipv6 localhost, который не определяется в конфигурации msql.

у меня также была проблема, где я должен был добавить 'localhost' вместо '127.0.0.1' к позволенным подсетям для того пользователя, не понимайте, почему (я использовал ipv4, и это было только что), но стоящий попытки.

8
ответ дан 28 November 2019 в 20:05

localhost, определенный в Вашем /private/etc/hosts файл?

1
ответ дан 28 November 2019 в 20:05

Вы могли проверить mysql/conf/my.conf (структура каталогов должна в значительной степени быть тем же на OSx) видеть если skip-networking не прокомментирован? Если так, добавьте a # перед строкой и перезапуском mysql-сервер.

У меня на самом деле была подобная проблема некоторое время назад (хотя это не было в OSx), таким образом, я думал, что это могло бы стоить того, чтобы попытаться.

2
ответ дан 28 November 2019 в 20:05

необходимо определить его в частном/и т.д./размещать, я думаю... или просто использую 127.0.0.1, потому что это - то же самое во всяком случае, просто псевдоним.

0
ответ дан 28 November 2019 в 20:05

Я смог воссоздать Ваши те же признаки на своем тестовом поле, надо надеяться, это поможет.

В MySQL пользователи определяются двумя частями (имя и хост). По умолчанию MySQL будет иметь 3 пользователей root:

mysql> SELECT host,user,password FROM mysql.user WHERE user='root';
+-----------------------+------+-------------------------------------------+
| host                  | user | password                                  |
+-----------------------+------+-------------------------------------------+
| localhost             | root |                                           |
| localhost.localdomain | root |                                           |
| 127.0.0.1             | root | *PASSWORD_HASH_GOES_HERE                  |
+-----------------------+------+-------------------------------------------+

Поле пароля или будет пробелом (никакой пароль) или хранить хеш. При установке пароля для одного определенного пользователя он автоматически не обновляет все, так как MySQL рассматривает их как различных пользователей.

Например:

mysql> set password for 'root'@'127.0.0.1' = password('Password');

обновит пароль для 'root'@'127.0.0.1', но нет 'root'@'localhost' или 'root'@'localhost.localdomain'

Смотрите на skip_name_resolve переменная:

mysql> show variables like 'skip_name_resolve';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| skip_name_resolve | ON    |
+-------------------+-------+
1 row in set (0.00 sec)

По умолчанию skip_name_resolve OFF, и попытается разрешить все IP-адреса к именам хостов. Например, если Вы соединяетесь как 'root'@'127.0.0.1', MySQL изменится, соединяют Вас как 'root'@'localhost'.

Если это ON, MySQL будет видеть и соединяться 'root'@'127.0.0.1' и 'root'@'localhost' как разделяют пользователей. И они могут или не могут иметь различных паролей, в зависимости от того, как они были установлены.


Таким образом, сначала я проверил бы для наблюдения любых различий в пароле: mysql> SELECT host,user,password FROM mysql.user WHERE user='root';

Если существует, можно зафиксировать их, или можно продолжить заниматься расследованиями.

Затем я проверил бы skip_name_resolve: mysql> show variables like 'skip_name_resolve';

Если это ON, Я узнал бы, где это устанавливается (например, /etc/my.cnf) и удалите его, если нет потребность в нем.

Надо надеяться, это выручает Вас!

1
ответ дан 28 November 2019 в 20:05

У меня возникла эта проблема, и я не мог ее понять. Я пробовал все, что мог, но безрезультатно.

Я обнаружил, что у меня есть .netrc в / root /, в котором есть информация.

Я удалил его, и проблема исчезла.

Можно войти в mysql, используя mysql -uroot -p теперь без проблем.

Я знаю, что это старый пост, но надеюсь, что это кому-то поможет.

1
ответ дан 28 November 2019 в 20:05

Для меня изменение разрешений на публичное чтение в родительском каталоге mysql.sock исправил проблему:

chmod 755 /var/lib/mysql
1
ответ дан 28 November 2019 в 20:05

Для меня встроенный php OSX настроен на использование другого unix-сокета, нежели mysql доморощенного. Поэтому он не может подключаться через localhost, который использует этот сокет.

Я исправил его быстрым взломом с помощью symlinking php's configured socket-path, чтобы указать на то, что на самом деле использует mysql.

sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock

Следующие диагностические команды были очень полезны.

Проверьте пути сокетов по умолчанию, используемые php и mysql:

php -i | fgrep 'mysql.default_socket'
mysql -e 'show variables where variable_name = "socket"'

Подключение с помощью указанного сокета:

php -r 'var_dump(mysql_connect("localhost:/tmp/mysql.sock", "user", "pass"));'
mysql --socket=/tmp/mysql.sock

Определите, какой сокет используется клиентом mysql для подключения:

lsof | egrep '^mysql .*(IPv|unix)'
5
ответ дан 28 November 2019 в 20:05

PHP все еще пытается использовать расположение сокета по умолчанию. Эта проблема может возникнуть, если вы переместили папку MariaDB / MySQL из / var / lib / mysql в другое место. Чтобы решить эту проблему, вам необходимо определить местоположение нового сокета в файле /etc/php.ini .

mysqli.default_socket =/newDBLocation/mysql/mysql.sock

Будьте осторожны, в зависимости от того, какой драйвер вы используете, вам, возможно, придется указать pdo_mysql.default_socket = !

Чтобы проверить текущий каталог, выполните следующую команду в mysql:

select @@datadir;
2
ответ дан 28 November 2019 в 20:05

Для людей, использующих CageFS с CloudLinux:

Я воссоздал / var / lib / mysql , потому что я перестраивал сервер MySQL с нуля ...

который размонтировал путь от cagefs. Я знаю, что это не связано, но я использовал cPanel и CloudLinux. Я не мог понять, почему соединение через сокет не работает, и наконец понял.

добавление / var / lib / mysql в /etc/cagefs/cagefs.mp (если уже есть, переходите к следующему шагу) и запуск

cagefsctl --remount-all

устранил проблему

1
ответ дан 28 November 2019 в 20:05

Теги

Похожие вопросы