MySQLがクラッシュし続ける：InnoDB：./ibdata1をロックできません、エラー：11

シンプルなWebサーバー（Debian 6.0 x86、1 GBのメモリと10 GBの空き容量を備えた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 Webサイトでトピックを見つけましたが、解決策はありません。

アイデアはありますか？

同じブログのあるコメントからの別のアプローチ：

これは私を助けました：

lsof -i：3306

次に、それを殺します（プロセス番号）

-9プロセスを殺す

例：キル-9 13498

その後、MySQLを再起動してください。

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

Ubuntu 14.04で。経由で再起動しようとすると、この問題が発生します

/etc/init.d/mysql restart

代わりに試してください

service mysql restart 

この問題の最も一般的な原因は、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,

多くの場合の解決策の主な違いは、2つのルール（dir自体と内部のすべてのファイル、doubleに注意**）とkmysqlがファイルをロックできるようにするオプションです。

これが誰かを助けることを願っています。

スペースをチェックして、100％であることを確認します

df -h

完全なように、.sockファイルは作成されません。

ファイルpid-fileの[mysql]セクションに パラメータがあることを確認してくださいmy.cnf。存在しない場合、unable 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の構成に何か問題があると思ったのはなぜですか。