MySQL continua a bloccarsi: InnoDB: impossibile bloccare ./ibdata1, errore: 11

Ho un server web semplice (Debian 6.0 x86, DirectAdmin con 1 GB di memoria e ancora 10 GB di spazio libero, versione mySQl 5.5.9), tuttavia il server mySQL continua a bloccarsi e devo interrompere tutti i processi mySQL per poterlo riavviare ancora.

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

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.

Ho trovato un argomento sul sito Web mySQL qui, tuttavia non esiste una soluzione.

Qualche idea qualcuno?

un altro approccio da un commento nello stesso blog:

questo mi ha aiutato:

lsof -i: 3306

Quindi uccidilo (il numero di processo)

uccidi -9 PROCESSO

es. uccidere -9 13498

Quindi prova a riavviare nuovamente MySQL.

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

con Ubuntu 14.04. Sto riscontrando questo problema quando provo a riavviare tramite

/etc/init.d/mysql restart

Invece prova

service mysql restart 

La causa più comune di questo problema sta provando ad avviare MySQL quando è già in esecuzione.

Per risolverlo, uccidi tutte le istanze in esecuzione di MySQL e quindi riavvialo usando i tuoi normali script di avvio, ad es service mysql start.

Non tentare di avviare MySQL manualmente quando si utilizzano versioni distribuite in pacchetti a meno che non si sia preparati per un mondo di dolore.

Soluzione

fare una copia dei file originali (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

Questo mi ha aiutato a risolverlo:

Elimina tutti i file ibdata e lascia che mysql li crei.

basta mysql:

service mysql stop

vai alla libreria mysql:

cd /var/lib/mysql/

sposta i file innodb da qualche parte nel caso ne avessi bisogno:

mv ib* /root/

avvia mysql:

service mysql start

È venuto qui da google dello stesso errore ripetuto ma con il codice di errore 13 ( InnoDB: Unable to lock ./ibdata1, error: 13). Dopo aver provato molte soluzioni su Internet, ne ho inventata una che mi ha aiutato (apparmor!)

Aggiungi queste righe alla configurazione /etc/apparmor.d/usr.sbin.mysqld(e ricarica naturalmente apparmor e mysql):

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

Le principali differenze tra le soluzioni spesso: due regole (per dir stesso e per tutti i file all'interno, notare il doppio **) e l' kopzione per consentire a mysql di bloccare i file.

Spero che questo aiuti qualcuno.

Controlla lo spazio per assicurarti che sia al 100%

df -h

Come se fosse pieno, non creerà il file .sock.

Verifica di avere i pid-fileparametri nella [mysql]sezione del my.cnffile. Se non è presente, unable to lock ...ibdata1.. error:1accadrà.

Semplice, ma più veloce di "cp -a". E ha aiutato quando "cp -a" e tutto il resto no.

1. service mysql stop && pkill -f mysql

Sbarazzati di tutti i processi mysql

2. vi /etc/mysql/my.cnf

Cambia il parametro datadir = / var / lib / mysql in datadir = / var / lib / mysql2 (o aggiungi se non hai)

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

Rinomina datadir con un nuovo nome

4. service mysql start

Prepara il tuo tamburello

Se nessuna delle altre soluzioni funziona, il problema probabilmente deriva da un'errata configurazione di AppArmor.

Quindi fai solo:

$ apt install apparmor-profiles

e quindi riavvia MySQL (nota quanto velocemente si riavvierà).

Ho notato che mancava un file relativo ad AppArmor quando facevo:

$ systemctl status mysql.service

Ecco perché ho pensato che qualcosa non andasse nella configurazione di AppArmor.