MySQL ulega awarii: InnoDB: Nie można zablokować ./ibdata1, błąd: 11

Mam prosty serwer WWW (Debian 6.0 x86, DirectAdmin z 1 GB pamięci i wciąż 10 GB wolnego miejsca, mySQl wersja 5.5.9), jednak serwer mySQL ciągle się zawiesza i muszę zabić wszystkie procesy mySQL, aby móc go zrestartować jeszcze raz.

/var/log/mysql-error.log wynik:

130210 21:04:26 InnoDB: Using Linux native AIO
130210 21:04:34 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:05:42 InnoDB: Completed initialization of buffer pool
130210 21:05:48 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:22 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:27 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:06:29 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:07:22 InnoDB: Completed initialization of buffer pool
130210 21:07:51 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:08:33 InnoDB: Completed initialization of buffer pool
130210 21:12:03 [Note] Plugin 'FEDERATED' is disabled.
130210 21:12:47 InnoDB: The InnoDB memory heap is disabled
130210 21:12:47 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
130210 21:12:47 InnoDB: Compressed tables use zlib 1.2.3
130210 21:12:47 InnoDB: Using Linux native AIO
130210 21:13:11 InnoDB: highest supported file format is Barracuda.
130210 21:13:23 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130210 21:14:05  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
130210 21:17:53  InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
130210 21:17:53  InnoDB: Operating system error number 11 in a file operation.

Znalazłem tutaj temat na stronie mySQL , jednak nie ma na to rozwiązania.

Jakieś pomysły?

inne podejście z jednego komentarza na tym samym blogu:

pomogło mi to:

lsof -i: 3306

Następnie zabij to (numer procesu)

zabij -9 PROCES

np. zabij -9 13498

Następnie spróbuj ponownie uruchomić MySQL ponownie.

przez http://www.webhostingtalk.com/archive/index.php/t-1070293.html

z Ubuntu 14.04. Ten problem występuje podczas próby ponownego uruchomienia za pośrednictwem

/etc/init.d/mysql restart

Zamiast tego spróbuj

service mysql restart 

Najczęstszą przyczyną tego problemu jest próba uruchomienia MySQL, gdy jest już uruchomiony.

Aby rozwiązać ten problem, zabij wszystkie działające instancje MySQL, a następnie uruchom go ponownie przy użyciu normalnych skryptów startowych, np service mysql start.

Nie próbuj uruchamiać MySQL ręcznie, gdy używasz wersji z pakietami dystrybucyjnymi, chyba że jesteś przygotowany na świat bólu.

Rozwiązanie

wykonaj kopię oryginalnych plików (ibdata1, ib_logfile0, ib_logfile1 ...).

mv ibdata1 ibdata1.bak 
cp -a ibdata1.bak ibdata1

http://cglreport.zhenhua.info/2008/08/mysql-error-unable-to-lock-ibdata1.html

Pomogło mi to rozwiązać:

Usuń wszystkie pliki ibdata i pozwól mysql je utworzyć.

zatrzymaj mysql:

service mysql stop

przejdź do biblioteki mysql:

cd /var/lib/mysql/

przenieś gdzieś pliki innodb na wypadek, gdyby były potrzebne:

mv ib* /root/

uruchom mysql:

service mysql start

Przyszedł tutaj z googlingu tego samego powtarzającego się błędu, ale z kodem błędu 13 ( InnoDB: Unable to lock ./ibdata1, error: 13). Po wypróbowaniu wielu rozwiązań w Internecie wymyśliłem takie, które mi pomogło (apparmor!)

Dodaj te wiersze do konfiguracji /etc/apparmor.d/usr.sbin.mysqld(i ponownie załaduj apparmor i mysql, oczywiście):

/path/to/mysql/data/ r,
/path/to/mysql/data/** rwk,

Główne różnice między często rozwiązaniami: dwie reguły (dla samego katalogu i dla wszystkich plików w środku, zwróć uwagę na podwójne **) i kopcja pozwalająca mysqlowi blokować pliki.

Mam nadzieję, że komuś to pomoże.

Sprawdź miejsce, aby upewnić się, że jest w 100%

df -h

Jak gdyby był pełny, nie utworzy pliku .sock.

Sprawdź, czy masz pid-fileparametr w [mysql]sekcji my.cnfpliku. Jeśli nie jest obecny, unable to lock ...ibdata1.. error:1nastąpi.

Proste, ale szybsze niż w przypadku „cp -a”. I pomógł, gdy „cp -a” i wszystko inne nie mogło.

1. service mysql stop && pkill -f mysql

Pozbądź się wszystkich procesów mysql

2. vi /etc/mysql/my.cnf

Zmień parametr datadir = / var / lib / mysql na datadir = / var / lib / mysql2 (lub po prostu dodaj, jeśli nie masz)

3. mv /var/lib/mysql /var/lib/mysql2

Zmień nazwę datadir na nową nazwę

4. service mysql start

Przygotuj tamburyn

Jeśli żadne z pozostałych rozwiązań nie działa, problem prawdopodobnie wynika z błędnej konfiguracji AppArmor.

Więc po prostu zrób:

$ apt install apparmor-profiles

a następnie uruchom ponownie MySQL (zauważ, jak szybko się zrestartuje).

Zauważyłem brakujący plik związany z AppArmor podczas wykonywania:

$ systemctl status mysql.service

Dlatego pomyślałem, że coś jest nie tak z konfiguracją AppArmor.