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 перед тестированием его.
Можно было включить IPv6, его очень возможный localhost решает к ipv6 localhost, который не определяется в конфигурации msql.
у меня также была проблема, где я должен был добавить 'localhost' вместо '127.0.0.1' к позволенным подсетям для того пользователя, не понимайте, почему (я использовал ipv4, и это было только что), но стоящий попытки.
Вы могли проверить mysql/conf/my.conf
(структура каталогов должна в значительной степени быть тем же на OSx) видеть если skip-networking
не прокомментирован? Если так, добавьте a #
перед строкой и перезапуском mysql-сервер.
У меня на самом деле была подобная проблема некоторое время назад (хотя это не было в OSx), таким образом, я думал, что это могло бы стоить того, чтобы попытаться.
необходимо определить его в частном/и т.д./размещать, я думаю... или просто использую 127.0.0.1, потому что это - то же самое во всяком случае, просто псевдоним.
Я смог воссоздать Ваши те же признаки на своем тестовом поле, надо надеяться, это поможет.
В 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
) и удалите его, если нет потребность в нем.
Надо надеяться, это выручает Вас!
У меня возникла эта проблема, и я не мог ее понять. Я пробовал все, что мог, но безрезультатно.
Я обнаружил, что у меня есть .netrc в / root /, в котором есть информация.
Я удалил его, и проблема исчезла.
Можно войти в mysql, используя mysql -uroot -p теперь без проблем.
Я знаю, что это старый пост, но надеюсь, что это кому-то поможет.
Для меня изменение разрешений на публичное чтение в родительском каталоге mysql.sock исправил проблему:
chmod 755 /var/lib/mysql
Для меня встроенный 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)'
PHP все еще пытается использовать расположение сокета по умолчанию. Эта проблема может возникнуть, если вы переместили папку MariaDB / MySQL из / var / lib / mysql в другое место. Чтобы решить эту проблему, вам необходимо определить местоположение нового сокета в файле /etc/php.ini .
mysqli.default_socket =/newDBLocation/mysql/mysql.sock
Будьте осторожны, в зависимости от того, какой драйвер вы используете, вам, возможно, придется указать pdo_mysql.default_socket = !
Чтобы проверить текущий каталог, выполните следующую команду в mysql:
select @@datadir;
Для людей, использующих CageFS с CloudLinux:
Я воссоздал / var / lib / mysql
, потому что я перестраивал сервер MySQL с нуля ...
который размонтировал путь от cagefs. Я знаю, что это не связано, но я использовал cPanel и CloudLinux. Я не мог понять, почему соединение через сокет не работает, и наконец понял.
добавление / var / lib / mysql
в /etc/cagefs/cagefs.mp
(если уже есть, переходите к следующему шагу)
и запуск
cagefsctl --remount-all
устранил проблему