MySQL이 계속 충돌 : InnoDB : ./ibdata1을 잠글 수 없음, 오류 : 11

간단한 웹 서버 (Debian 6.0 x86, 1GB의 메모리와 10GB의 여유 공간이있는 DirectAdmin, mySQl 버전 5.5.9)가 있지만 mySQL 서버가 계속 충돌하고 다시 시작할 수 있도록 모든 mySQL 프로세스를 종료해야합니다 다시.

/var/log/mysql-error.log 산출:

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.

mySQL 웹 사이트 에서 주제를 찾았 지만 해결책이 없습니다.

어떤 아이디어가 있습니까?

동일한 블로그의 한 의견에서 다른 접근 방식 :

이것은 나를 도왔다 :

lsof -i : 3306

그런 다음 프로세스 번호를 제거하십시오.

처치 -9 프로세스

예 : kill -9 13498

그런 다음 MySQL을 다시 시작하십시오.

http://www.webhostingtalk.com/archive/index.php/t-1070293.html을 통해

우분투 14.04로. 통해 다시 시작하려고 할 때이 문제가 발생합니다

/etc/init.d/mysql restart

대신 시도하십시오

service mysql restart 

이 문제의 가장 일반적인 원인은 MySQL이 이미 실행 중일 때 MySQL을 시작하려고 시도하는 것입니다.

이를 해결하려면 실행중인 MySQL 인스턴스를 모두 종료 한 다음 일반 시작 스크립트 (예 :)를 사용하여 다시 시작하십시오 service mysql start.

배포 패키지 버전을 사용할 때 상처를 입을 준비가되어 있지 않으면 MySQL을 수동으로 시작하지 마십시오.

해결책

원본 파일 (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

이것은 나를 해결하는 데 도움이되었습니다.

모든 ibdata 파일을 삭제하고 mysql이 생성하도록하십시오.

MySQL을 중지 :

service mysql stop

mysql 라이브러리로 이동하십시오.

cd /var/lib/mysql/

필요한 경우 innodb 파일을 다른 곳으로 옮기십시오.

mv ib* /root/

MySQL을 시작 :

service mysql start

동일한 반복 오류가 있지만 오류 코드 13 ( InnoDB: Unable to lock ./ibdata1, error: 13)으로 인터넷 검색을했습니다 . 인터넷 주위에 많은 솔루션을 시도한 후 나를 도와주는 솔루션을 발명했습니다 (의류!)

이 줄을 설정에 추가하십시오 /etc/apparmor.d/usr.sbin.mysqld(물론 apparmor와 mysql을 다시로드하십시오).

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

종종 솔루션의 주요 차이점 : 두 가지 규칙 (dir 자체와 내부의 모든 파일에 대해 double 참조 **)과 kmysql이 파일을 잠글 수있는 옵션.

이것이 누군가를 돕기를 바랍니다.

공간이 100 %인지 확인하십시오

df -h

가득 차있는 것처럼 .sock 파일을 만들지 않습니다.

파일 섹션에 pid-file매개 변수 가 있는지 확인 하십시오. 존재하지 않으면 발생합니다.[mysql]my.cnfunable to lock ...ibdata1.. error:1

"cp -a"보다 간단하지만 빠릅니다. 그리고 "cp -a"와 다른 모든 것들이 할 수 없었을 때 도움이되었습니다.

1. service mysql stop && pkill -f mysql

모든 mysql 프로세스를 제거하십시오

2. vi /etc/mysql/my.cnf

datadir = / var / lib / mysql 매개 변수를 datadir = / var / lib / mysql2로 변경하십시오 (또는없는 경우 추가하십시오).

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

datadir을 새로운 이름으로 바꾸십시오

4. service mysql start

탬버린 준비

다른 솔루션이 작동하지 않으면 AppArmor의 잘못된 구성으로 인한 문제 일 수 있습니다.

그래서 그냥하십시오 :

$ apt install apparmor-profiles

그런 다음 MySQL을 다시 시작하십시오 (다시 얼마나 빨리 시작되는지 알 수 있습니다).

다음을 수행 할 때 AppArmor와 관련된 파일이 누락 된 것으로 나타났습니다.

$ systemctl status mysql.service

따라서 AppArmor의 구성에 문제가 있다고 생각한 이유는 무엇입니까?