Co powinien zawierać mysqld.sock, dlaczego go nie mam?


22

Czy ktoś wie, dlaczego mój /var/run/mysqld/mysqld.sockplik gniazda nie byłby na moim komputerze podczas instalacji (lub ponownej instalacji) MySQL 5.1?

W tej chwili, kiedy próbuję uruchomić serwer za pomocą mysqld, dostaję błędy typu „ Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connectale”, ale utworzenie pustego pliku o tej nazwie (jak sugerowano na forach ubuntu) nie powiodło się.

Mysql i postgres działały dobrze, dopóki jakiś czas temu nie uaktualniłem do natty; Spędziłem godziny, przeglądając obie bazy danych, próbując dowiedzieć się, co się dzieje. Mogę zrezygnować z postgres, ale nie mogę pracować bez kopii roboczej mysql.

Najdziwniejsza część: używam Kubuntu i rozumiem, że KDE używa mysql do przechowywania uprawnień użytkowników itp. Nie mam żadnych dziwnych problemów z uprawnieniami; czy mogę to rozumieć tak, że (jakoś?) MySQL faktycznie działa?

Może te pliki gniazd żyją w innym miejscu w natty? Czy łatwiej byłoby po prostu ponownie zainstalować system operacyjny? W tym momencie jestem otwarty na wszelkie sugestie, które przestaną marnować mój czas.


Najpierw musisz uruchomić serwer mysql, a następnie plik /var/run/mysqld/mysqld.sockzostanie utworzony. Jak powiedział @Paul, musisz usunąć każdy plik umieszczony w tej lokalizacji.
Evan Hu,

Odpowiedzi:


18

Plik gniazda tak naprawdę nie zawiera danych, tylko je przenosi. Jest to specjalny, nietypowy typ pliku utworzony za pomocą specjalnych wywołań / poleceń systemowych. To nie jest zwykły plik.

To jest jak potok, którego serwer i klienci mogą używać do łączenia i wymiany żądań i danych. Ponadto jest używany tylko lokalnie. Jego znaczenie ma jedynie uzgodnione miejsce spotkania w systemie plików.

Utworzenie zwykłego, starego pliku i umieszczenie go w tej lokalizacji może faktycznie kolidować z tworzeniem go przez serwer ... i tym samym uniemożliwić lokalnym klientom łączenie się z serwerem.

Moje zalecenie to usunięcie dowolnego pliku umieszczonego w lokalizacji. Specjalny plik gniazda jest tworzony przez serwer.


1
Dziękuję za wyjaśnienie plików gniazda i przepraszam za źle sformułowane pytanie: moim pierwotnym problemem było to, że brakowało pliku gniazda - błąd, który mysql ciągle Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect
zgłaszał

ale jak to powstaje? bo wciąż go nie mam ..: -jak jakiś pomysł?
jpganz18

Prawdopodobnie masz klienta MySQL, który oczekuje, że gniazdo znajduje się w tej lokalizacji, ale serwer go tam nie tworzy (lub serwer nie działa). Jeśli serwer jest uruchomiony, poszukaj w / tmp lub użyj polecenia find lub locate to znajdź plik gniazda, a następnie uruchom klienta mysql z -S <ścieżka do pliku gniazda>
sed_and_done

20

Po określeniu host=localhostklient mysql spróbuje zalogować się do serwera mysql przy użyciu potoku nazwanego Unix, który wymaga .sockpliku.

Można to obejść, określając host = 127.0.0.1. Spowoduje to, że klient mysql będzie używał protokołu TCP do łączenia się z serwerem.

Zaczerpnięte z dokumentacji MySQL :

mysql --host=127.0.0.1 --port=3306 --user=your_uname --password=your_pass

To właściwie genialna (i bardzo potrzebna) odpowiedź, ponieważ historycznie rzecz biorąc widziałem mysql.sockznikanie bez żadnego powodu w każdej wersji MySQL, z którą współpracowałem (powrót do 4.0). Kiedy tak się dzieje, loguję się w ten sposób, ale używam --protocol=tcpzamiast --port. Podczas zamykania mysql usługa szuka pliku gniazda. Tak więc bieganie service mysql stopnie powiedzie się. Aby obejść brakujący ból głowy związany z plikiem gniazda, biegam mysqladmin -h127.0.0.1 --protocol=tcp -uroot -p shutdown. Och, BTW, +1 !!!
RolandoMySQLDBA

Dziękuję Ci. To była moja pierwsza odpowiedź w dowolnym miejscu online :) I tak. Alternatywną metodą użycia protokołu TCP jest podanie --protocol = tcp.
scott

14

Gniazdo to specjalny pseudoplik służący do przesyłania danych przez odczyt i zapis, a nie przechowywanie danych.

Plik gniazda jest tworzony podczas uruchamiania usługi i usuwany po zakończeniu usługi. Lokalizacja pliku jest zdefiniowana w następujący /etc/my.cnfsposób:

[mysqld]
socket=/var/run/mysql/mysql.sock

8

W moim przypadku uruchomione mysqld_safeutworzyło nowy mysqld.sockplik.

$ cd /etc/init.d/
$ mysqld_safe

Prawdopodobnie nie otrzymasz odpowiedzi z powrotem, ale jeśli ponownie uruchomisz sesję, plik mysqld.sock będzie gdzieś. Znajdź za pomocą

$ sudo find / -type s | grep mysqld.sock

2

Miałem ten sam problem z brakującym plikiem mysqld.sock. Poszedłem do katalogu zawierającego mysql, a mianowicie /usr/binw moim przypadku. Potem wydałem polecenie

mysql mysql --host=localhost --password=whatever --port=3306

Podwójny mysql nie jest literówką, ale raczej mysql to baza danych, która zawsze będzie istnieć w nowej instalacji MySQL. Nie wiem --host, --passwordczy --portsą potrzebne, ale ponieważ działało dla mnie przy użyciu tych parametrów, uwzględniam je. Kiedy MySQL pojawił się, przeszedłem do tabeli użytkowników, ustawiając hasło dla roota. Po uruchomieniu MySQL utworzono brakujący plik gniazda. Mam nadzieję, że to komuś pomoże, skoro walczyłem kilka dni.


1

Jeśli używasz nginx php-fastcgi i masz błąd 502 Bad Gateway, to musisz spojrzeć na konfigurację hosta wirtualnego w pliku konfiguracyjnym nginx. Musisz ustawić lub poprawić fastcgi_passparametr. fastcgi_passJest to zmienna do ustawienia połączenia gniazda między CGI nginx a php.

Innym problemem jest to, że binarny skrypt startowy mógł pominąć następujące wpisy (ważne) otwarte przy pomocy: nano /usr/bin/php-fastcgi

SOCKET=/var/run/php-fastcgi/php-fastcgi.socket
PIDFILE=/var/run/php-fastcgi/php-fastcgi.pid

Cała zawartość mojego skryptu startowego / usr / bin / php-fastcgi:

#!/bin/bash

FASTCGI_USER=www-data
FASTCGI_GROUP=www-data
SOCKET=/var/run/php-fastcgi/php-fastcgi.socket
PIDFILE=/var/run/php-fastcgi/php-fastcgi.pid
CHILDREN=6
PHP5=/usr/bin/php5-cgi

/usr/bin/spawn-fcgi -s $SOCKET -P $PIDFILE -C $CHILDREN -u $FASTCGI_USER -g $FASTCGI_GROUP -f $PHP5
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.