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)
ping localhost
i zobacz, co mówi.Odpowiedzi:
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:
Twój plik powinien być podobny. Wtedy twój problem powinien zostać rozwiązany. Nie zapomnij zrestartować serwera MySQL przed jego przetestowaniem.
źródło
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ć.
źródło
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.
Poniższe polecenia diagnostyczne były bardzo pomocne.
Sprawdź domyślne ścieżki gniazd używane przez php i mysql:
Połącz używając określonego gniazda:
Określ, jakiego rodzaju klienta mysql używa gniazdo do połączenia:
źródło
Czy możesz sprawdzić
mysql/conf/my.conf
(struktura katalogów powinna w zasadzie być taka sama w systemie OSx), aby sprawdzić, czy nieskip-networking
jest 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ć.
źródło
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 .
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:
źródło
Czy
/private/etc/hosts
plik localhost jest zdefiniowany w twoim pliku?źródło
/private
? Nigdy wcześniej tego nie widziałemUdał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:
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:
zaktualizuje hasło dla
'root'@'127.0.0.1'
, ale nie'root'@'localhost'
lub'root'@'localhost.localdomain'
Spójrz na
skip_name_resolve
zmienną:Domyślnie
skip_name_resolve
jestOFF
i 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!
źródło
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.
źródło
Dla mnie zmiana uprawnień do publicznego odczytu w katalogu nadrzędnym mysql.sock rozwiązała problem:
źródło
Dla osób korzystających z CageFS z CloudLinux:
Odtworzyłem,
/var/lib/mysql
ponieważ 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/mysql
do/etc/cagefs/cagefs.mp
(jeśli już tam jest przejście do następnego kroku) i uruchamianienaprawiono problem
źródło
/etc/cagefs/cagefs.mp
ale działałocagefsctl --remount-all
to naprawić. Dzięki stary!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.
źródło