MySQL nie może połączyć się przez „localhost”, tylko 127.0.0.1

to jest dla mnie nieco tajemnicą. Jedynym sposobem, w jaki mogę połączyć się z MySQL, jest wywołanie go przez „127.0.0.1” ... na przykład mój skrypt połączenia PHP NIE będzie działał z hostem lokalnym

Korzystam z systemu Mac OS X Lion, wbudowanego apache2, MySQL, PHP, phpMyAdmin

mysqladmin:

count                             0
debug-check                       FALSE
debug-info                        TRUE
force                             FALSE
compress                          FALSE
character-sets-dir                (No default value)
default-character-set             auto
host                              (No default value)
no-beep                           FALSE
port                              0
relative                          FALSE
socket                            (No default value)
sleep                             0
ssl                               FALSE
ssl-ca                            (No default value)
ssl-capath                        (No default value)
ssl-cert                          (No default value)
ssl-cipher                        (No default value)
ssl-key                           (No default value)
ssl-verify-server-cert            FALSE
user                              (No default value)
verbose                           FALSE
vertical                          FALSE
connect-timeout                   43200
shutdown-timeout                  3600
plugin-dir                        (No default value)
default-auth                      (No default value)

MySQL spróbuje połączyć się z gniazdem unix, jeśli powiesz mu, aby połączyć się z „localhost”. Jeśli każesz mu połączyć się z 127.0.0.1, zmuszasz go do połączenia z gniazdem sieciowym. Prawdopodobnie więc skonfigurowałeś MySQL tak, aby nasłuchiwał tylko gniazda sieciowego, a nie gniazda systemu plików.

Trudno powiedzieć, co dokładnie jest nie tak z gniazdem unix. Ale polecam przeczytać tę stronę w podręczniku MySQL. To powinno ci pomóc.

AKTUALIZACJA: W oparciu o zaktualizowane pytanie: Parametr „gniazdo” powinien być mniej więcej taki: „/var/lib/mysql/mysql.sock”. Ta strona w podręczniku zawiera więcej informacji.

Oto początek mojego pliku /etc/my.cnf:

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

Twój plik powinien być podobny. Wtedy twój problem powinien zostać rozwiązany. Nie zapomnij zrestartować serwera MySQL przed jego przetestowaniem.

Możliwe, że masz włączony IPv6, jego bardzo prawdopodobny lokalny host rozwiązuje się do lokalnego hosta ipv6, który nie jest zdefiniowany w konfiguracji msql.

Ive miał również problem polegający na tym, że musiałem dodać „localhost” zamiast „127.0.0.1” do dozwolonych podsieci dla tego użytkownika, nie rozumiem dlaczego (korzystałem z ipv4 i było to jakiś czas temu), ale warto spróbować.

Dla mnie wbudowane php OSX jest skonfigurowane do używania innego gniazda unix niż mysql homebrew. Dlatego nie może połączyć się przez localhost, który wykorzystuje to gniazdo.

Naprawiłem to szybkim włamaniem, łącząc skonfigurowaną ścieżkę gniazda php, aby wskazać ten, którego faktycznie używa mysql.

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

Poniższe polecenia diagnostyczne były bardzo pomocne.

Sprawdź domyślne ścieżki gniazd używane przez php i mysql:

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

Połącz używając określonego gniazda:

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

Określ, jakiego rodzaju klienta mysql używa gniazdo do połączenia:

lsof | egrep '^mysql .*(IPv|unix)'

Czy możesz sprawdzić mysql/conf/my.conf(struktura katalogów powinna w zasadzie być taka sama w systemie OSx), aby sprawdzić, czy nie skip-networkingjest to zalecane? Jeśli tak, dodaj #przed wierszem i zrestartuj serwer mysql.

W przeszłości miałem podobny problem (chociaż nie było to w OSx), więc pomyślałem, że warto spróbować.

PHP wciąż próbuje użyć domyślnej lokalizacji gniazda. Ten problem może pojawić się, jeśli folder MariaDB / MySQL został przeniesiony z / var / lib / mysql do innej lokalizacji. Aby rozwiązać problem, musisz zdefiniować lokalizację nowego gniazda w pliku /etc/php.ini .

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

Uważaj, w zależności od używanego sterownika może być konieczne określenie pdo_mysql.default_socket = !

Aby sprawdzić bieżący katalog, uruchom następujące polecenie w mysql:

select @@datadir;

Czy /private/etc/hostsplik localhost jest zdefiniowany w twoim pliku?

Udało mi się odtworzyć te same objawy na moim polu testowym, mam nadzieję, że to pomoże.

W MySQL użytkownicy są definiowani przez dwie części (nazwę i hosta). Domyślnie MySQL będzie miał 3 użytkowników 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                  |
+-----------------------+------+-------------------------------------------+

Pole hasła albo będzie puste (brak hasła), albo będzie przechowywany skrót. Jeśli ustawisz hasło dla jednego określonego użytkownika, nie aktualizuje ono automatycznie wszystkich, ponieważ MySQL widzi je jako różnych użytkowników.

Na przykład:

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

zaktualizuje hasło dla 'root'@'127.0.0.1', ale nie 'root'@'localhost'lub'root'@'localhost.localdomain'

Spójrz na skip_name_resolvezmienną:

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

Domyślnie skip_name_resolvejest OFFi będzie próbował rozwiązać wszystkie adresy IP z nazwami hostów. Na przykład, jeśli łączysz się jako 'root'@'127.0.0.1', MySQL zmieni łączenie się jako 'root'@'localhost'.

Jeśli jest ON, MySQL będzie zobaczyć i połączyć 'root'@'127.0.0.1'i 'root'@'localhost'jako oddzielne użytkowników. I mogą mieć różne hasła, w zależności od ich ustawienia.

Najpierw sprawdziłbym, czy są różnice w hasłach: mysql> SELECT host,user,password FROM mysql.user WHERE user='root';

Jeśli tak, możesz je naprawić lub możesz kontynuować badanie.

Następnie sprawdziłbym skip_name_resolve: mysql> show variables like 'skip_name_resolve';

Jeśli tak ON, dowiedziałbym się, gdzie jest ustawiany (na przykład /etc/my.cnf) i usunę go, chyba że zajdzie taka potrzeba.

Mam nadzieję, że to ci pomoże!

Miałem ten problem i nie mogłem go zrozumieć. Próbowałem wszystkiego, co w mojej mocy, bezskutecznie.

Odkryłem, że mam plik .netrc w katalogu / root /, który zawierał informacje.

Usunąłem go i problem zniknął.

W stanie zalogować się do mysql przy użyciu mysql -uroot -p bez problemu teraz.

Wiem, że to stary post, ale mam nadzieję, że to komuś pomoże.

Dla mnie zmiana uprawnień do publicznego odczytu w katalogu nadrzędnym mysql.sock rozwiązała problem:

chmod 755 /var/lib/mysql

Dla osób korzystających z CageFS z CloudLinux:

Odtworzyłem, /var/lib/mysqlponieważ odbudowałem serwer MySQL od zera ...

który odmontował ścieżkę z cagefs. Wiem, że to nie ma związku, ale korzystałem z cPanel i CloudLinux. Nie mogłem zweryfikować, dlaczego połączenie przez gniazdo nie działa, i wreszcie zrozumiałem.

dodawanie /var/lib/mysqldo /etc/cagefs/cagefs.mp (jeśli już tam jest przejście do następnego kroku) i uruchamianie

cagefsctl --remount-all

naprawiono problem

musisz to zdefiniować w prywatnych / etc / hosts Myślę, że ... lub po prostu użyj 127.0.0.1, ponieważ tak czy inaczej jest to tylko alias.