uruchomienie serwera mysql nie powiodło się

22

Używam serwera Ubuntu. Kiedy próbowałem zalogować się do mysql (który działał), otrzymałem następujący błąd

ERROR 2002 (HY000): Can't connect to local MySQL server through socket         '/var/run/mysqld/mysqld.sock' (2)

Ale plik mysqld.sock nie istnieje w folderze /var/run/mysqld . Po uruchomieniu polecenia ps aux | grep mysql zdałem sobie sprawę, że serwer mysql nie był uruchomiony.

Następnie spróbowałem ponownie uruchomić serwer mysql za pomocą

service mysql start
service mysql restart
/etc/init.d/mysql start

Ale proces uruchamiania nie powiódł się we wszystkich 3 przypadkach. Pliki /var/log/mysql/mysql.log i /var/log/mysql/mysql.err są puste.

Ale /var/log/error.log pokazuje następujące informacje:

140425 12:49:05 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140425 12:49:05 [Note] Plugin 'FEDERATED' is disabled.
140425 12:49:05 InnoDB: The InnoDB memory heap is disabled
140425 12:49:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140425 12:49:05 InnoDB: Compressed tables use zlib 1.2.8
140425 12:49:05 InnoDB: Using Linux native AIO
140425 12:49:05 InnoDB: Initializing buffer pool, size = 3.0G
140425 12:49:05 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 26214400 bytes!
140425 12:49:05 [ERROR] Plugin 'InnoDB' init function returned error.
140425 12:49:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140425 12:49:05 [ERROR] /usr/sbin/mysqld: unknown variable 'record_buffer=64M'
140425 12:49:05 [ERROR] Aborting

140425 12:49:05 [Note] /usr/sbin/mysqld: Shutdown complete
    
zadawane ananth 25.04.2014, 09:31
źródło

10 odpowiedzi

23

Otwórz terminal ( Ctrl + Alt + t ) i wykonaj następujące czynności:

sudo service mysql stop
sudo rm /var/lib/mysql/ib_logfile0
sudo rm /var/lib/mysql/ib_logfile1

i skomentuj linię record_buffer=64M w /etc/mysql/my.cnf [1 ]

, a następnie uruchom ponownie msyql, używając:

sudo service mysql restart

(Źródło)

    
odpowiedział jobin 25.04.2014, 10:36
źródło
8

To rozwiązało mój problem:

mkdir /var/run/mysqld

touch /var/run/mysqld/mysqld.sock

chown -R mysql /var/run/mysqld

/etc/init.d/mysql restart

    
odpowiedział user520064 12.11.2015, 19:09
źródło
7

Rozwiązałem problem w następujący sposób:

chown -R mysql:mysql /var/lib/mysql
mysql_install_db --user=mysql -ldata=/var/lib/mysql/

W innym kontekście zmierzyłem się z tym, ponieważ demon mysql nie mógł się uruchomić. Więc uruchom demona za pomocą polecenia - mysqld start , a następnie spróbuj uruchomić usługę.

    
odpowiedział Sudheesh.M.S 27.03.2015, 17:16
źródło
2

Miałem ten sam komunikat o błędzie i takie samo puste w plikach dziennika. W moim pliku konfiguracyjnym (my.cnf) określiłem, że chcę używać tabel myisam, dodając tę ​​linię w [mysqld] -section:

default-table-type = myisam

Po aktualizacji mysql wydaje się, że to powoduje, że mysql się nie uruchamia. Zmieniłem to na:

default-storage-engine = myisam

a teraz wszystko działa poprawnie.

    
odpowiedział Lars Olav Tveito 07.07.2015, 12:16
źródło
1

Zwiększenie dostępnej pamięci RAM poprzez dodanie nowego obszaru wymiany może również pomóc. Kroki to tutaj

Upewnij się, że utworzyłeś / swapfile o rozmiarze mniejszym niż dostępne miejsce wyświetlone

df -h

Na przykład dla mnie wyjście df-h było:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  1.2G  6.3G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            492M   12K  492M   1% /dev
tmpfs           100M  336K   99M   1% /run

Więc stworzyłem używając 2 G

sudo fallocate -l 2G /swapfile

A potem po prostu uruchom usługę

sudo /etc/init.d/mysql restart

Mam nadzieję, że to pomaga. Wszystko co najlepsze.

    
odpowiedział Vivek 21.06.2016, 13:24
źródło
1

Moje rozwiązanie:

Sprawdź, czy we wszystkich /etc/rc1.d ... /etc/rc5.d skrypt mysql zaczyna się od S (Ex S10mysql), a nie K AS K10mysql.

Objaśnienie: Przedrostek K ładuje się z zatrzymaniem, rodzaj usługi zabijania; Prefiks S rozpoczyna się od parametru start.

execute in terminal:   
(command        script action  runlevel)
---------------------------------------
sudo update-rc.d mysql enable  2
sudo update-rc.d mysql enable  3
sudo update-rc.d mysql enable  4
sudo update-rc.d mysql enable  5
    
odpowiedział Sergio Abreu 02.12.2016, 08:58
źródło
0

Usuń plik /var/lib/mysql/.run-mysql_upgrade i powinien się uruchomić

;)

"Z wielką siłą wiąże się wielka odpowiedzialność"

    
odpowiedział Adrian Pule 09.10.2014, 01:26
źródło
0

Miałem ten problem, gdy ustawiłem max_allowed_packet = 0.5M w /etc/mysql/my.cnf .

Rozwiązałem go, zmieniając max_allowed_packet na 1M .

    
odpowiedział Elliot Schep 13.09.2017, 19:56
źródło
0

Poniższa komenda rozwiązuje mój problem i może zacząć po niej mysql. (Może się to przydać w niektórych przypadkach)

chown -R mysql: /var/lib/mysql
    
odpowiedział zhilevan 10.12.2017, 09:44
źródło
0

W moim przypadku był to problem z przestrzenią. Sprawdź, czy masz wystarczająco dużo miejsca.

z /var/log/mysql/error.log Otrzymałem kilka wskazówek z dwóch linii:

2018-08-04T05:25:29.519139Z 0 [ERROR] InnoDB: Write to file ./ibtmp1failed at offset 3145728, 1048576 bytes should have been written, only 704512 were writt$
2018-08-04T05:25:29.519145Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'

Widzę, że jest to problem z przestrzenią.

root@xxx:/home/user1# df -h
Filesystem                            Size  Used Avail Use% Mounted on
udev                                  477M     0  477M   0% /dev
tmpfs                                 100M   11M   89M  11% /run
/dev/mapper/server1--osticket--vg-root  8.3G  7.9G     0 100% /
tmpfs                                 497M     0  497M   0% /dev/shm
tmpfs                                 5.0M     0  5.0M   0% /run/lock
tmpfs                                 497M     0  497M   0% /sys/fs/cgroup
/dev/vda1                             472M  467M     0 100% /boot
tmpfs                                 100M     0  100M   0% /run/user/1000

Stąd widziałem, że na wirtualnym serwerze /dev/mapper/server1--osticket--vg-root 8.3G 7.9G 0 100% / pozostało za mało miejsca. I pomyślałem przy migracji lub zwiększeniu wirtualnego dysku, ale najpierw zdecydowałem się usunąć niepotrzebne pliki.

Musiałem więc wyczyścić pamięć podręczną i pliki, które nie były potrzebne:

#apt-get clean
#apt-get -f autoremove

Następnie nie zapomnij usunąć plików logów uszkodzonych przez mysql. Zostaną wygenerowane ponownie po restarcie mysql

#service mysql stop
#cd /var/lib/mysql
#rm ib_logfile*
#service mysql start

Sprawdź swoją usługę serwera mysql i prawdopodobnie działa

root@server1-osticket:/var/lib/mysql# service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-08-04 23:07:24 WAT; 7min ago
  Process: 1559 ExecStartPost=/usr/share/mysql/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 1549 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 1558 (mysqld)
    Tasks: 29
   Memory: 280.3M
      CPU: 589ms
   CGroup: /system.slice/mysql.service
           └─1558 /usr/sbin/mysqld

Aug 04 23:07:19 server1-osticket systemd[1]: Starting MySQL Community Server...
Aug 04 23:07:24 server1-osticket systemd[1]: Started MySQL Community Server.
root@server1-osticket:/var/lib/mysql#

Sprawa zamknięta. Mam nadzieję, że to pomoże.

    
odpowiedział sukupandachu 04.08.2018, 20:40
źródło

Przeczytaj inne pytania na temat tagów