CloudGarage

最終更新日 2019.11.07ID #1257

Mysqlが起動しません。ログにはInnoDBに関するエラーが書かれています。

以下いずれも当てはまるという場合、データベースサーバーのInnoDBが破損している可能性があります。
※ InnoDBの破損は 予兆なく発生ことがあります。CloudGarageでも移行先の別環境であっても発生する可能性があります。

 1) ウェブページに「Error establishing a database connection」というログが出て
  サイトが見えない
 2) インスタンスの再起動、あるいは、Mysql(MariaDB)の再起動を試みたが失敗する
   Mysql 再起動コマンドの例 
   # systemctl start mysql
 3) データベースのログファイル【/var/log/mysql/mysqld.log】には
   以下のようなエラーが出ている

InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

コマンド操作はサポート対象外ではございますが、参考情報を掲載いたします。
■InnoDBの修復手順概要
 1)データベースフォルダを丸ごとバックアップを取る
 2)InnoDB修復モードでMysqlを起動する
 3)すべてのデータベースをダンプする
 4)Mysqlを停止して、一部のファイル、フォルダ以外をすべて削除する
 5)Mysqlを通常モードで起動しなおす
 6)3)で取得したデータベースをリストアする
 7)データベースフォルダ内に想定されたフォルダが生成されているか確認。
 できていなかったら Mysqlを一旦停止し、バックアップからフォルダをコピー、
 その後Mysqlを起動しなおす
 8)Mysqlのログのエラー状況の有無、および ウェブサイトの確認
詳細は以下のとおりです。

1)データベースフォルダを丸ごとバックアップを取る

# mkdir /root/mysql_YYMMDD
# cp -a /var/lib/mysql/ /root/mysql_YYMMDD/
# ls -l /root/mysql_YYMMDD/
total 4
drwxr-xr-x 5 mysql mysql 4096 ** * *** mysql

2)InnoDB修復モードでMysqlを起動する

Mysqlの起動状況は以下で確認できる
# systemctl status mysql
Active: active (running)」の行があれば起動中。
Active: failed (Result: exit-code) 」の行があれば停止中。

設定ファイル(/etc/my.cnf )のバックアップを取っておく

# cp -pi /etc/my.cnf /etc/my.cnf.YYMMDD

設定ファイルを編集する

# vi /etc/my.cnf

ファイル内に「[mysqld]」の記載があればその下に「innodb_force_recovery = 1」
(1の数字は変更となる可能性がある)を記載する。
「[mysqld]」の記載がなければ、以下の2行を追記し保存する。

[mysqld]
innodb_force_recovery = 1


その後、現在mysqlが停止なら
【起動コマンド】
# systemctl start mysql
でmysqlの起動を試し、起動中なら以下で再起動を試す。
【再起動コマンド】
# systemctl restart mysql

ただし、「innodb_force_recovery = 1」では相変わらず同様のエラーが出現し、
なにも解決しない場合がある。

その場合は、設定ファイルを
「innodb_force_recovery = 2」に変更し、mysql再起動、だめなら
「innodb_force_recovery = 3」に変更し、mysql再起動を試すなどすることも有効である。

このパラメーターについてはMysql公式マニュアルを参照のこと。4以上に設定すると
データファイルが恒久的に破損する可能性があり危険度が高い旨も公式マニュアルには記載されている。

3)修復モードで、Mysqlが起動している状態であればすべてのデータベースをダンプする

複数のコマンド例があるが以下は一例

# mysqldump -u root -p -A  > /root/mysql_YYMMDD/dumpdata.sql
Enter password:
( パスワードはsftpパスワードと同じ ) 

4)Mysqlを停止し、/var/lib/mysql/mysql以下のファイル、/var/lib/mysql/mysqlフォルダ以外をすべて削除する

# systemctl stop mysql

# rm -rf ´ls -d /var/lib/mysql/* | grep -v "/var/lib/mysql/mysql"´
# ls -l /var/lib/mysql/
total 4
drwx--x--x 2 mysql mysql 4096 *** *** mysql

5)Mysqlを通常モードで起動しなおす

修復モード「innodb_force_recovery = 1(もしくは2,3)」の行を
/etc/my.cnf から削除する。
その後、mysqlを起動。

# vi /etc/my.cnf
  ※innodb_force_recovery = ○ の行を削除するかコメントアウトして保存しなおす

# systemctl start mysql

6)3)で取得したデータベースをリストアする

# mysql -u root -p < /root/mysql_YYMMDD/dumpdata.sql
Enter password:
( パスワードはsftpパスワードと同じ )

7)データベースフォルダ内に想定されたフォルダが生成されているか確認。
できていなかったら Mysqlを一旦停止し、バックアップからフォルダをコピー、その後Mysqlを起動しなおす

リストア後の「/var/lib/mysql/」フォルダ以下とバックアップフォルダ「/root/mysql_YYMMDD/mysql/」を比較する。本来復元されているべき、オリジナルのデータベースフォルダは出来上がっているか確認する。

本来あったはずの「wpdata_web」というフォルダがバックアップ側にあって、
リストア後の/var/lib/mysql/以下には出来上がっていなかった場合は、一旦Mysqlをとめて
フォルダごとコピーを行ってから再起動してみる。

ただし、できあがったファイルの上書きなどはしないように注意。あえて残しておいた/var/lib/mysql/mysql以下も当然、操作はしないようにする。


<不足しているフォルダがあったときの参考作業例>
# systemctl stop mysql

# cp -pri /root/mysql_YYMMDD/mysql/wpdata_web/  /var/lib/mysql/
# ls -l /var/lib/mysql/

# systemctl start mysql

8)Mysqlのログのエラー状況の有無、および ウェブサイトの確認

InnoDBが破損しているときは、InnoDB以外にも設定を疑うような内容のエラーログが
出ているが、破損が修復されたときは、エラー行は大幅に減っている。
ウェブサイト上にもデータベース接続エラーが出ていないか確認する

キーワード検索