WordPressのデータベース接続エラーについて

Day:2013.10.30 3:40 Comments: 12

VPS WordPress

最近ブログがやたらエラーになる。

データベース接続エラーになり、WordPressにログインできなくなることが頻発。

VPSをやめてどこかに移転しようか考え中。

自鯖も考え物だね。

というわけで、ブログ主が体験したデータベース接続エラーの症例をまとめてみた。

症例１：アクセス過多

データベース接続エラーでも色々種類がある。

一番簡単に復旧できるのがこれ。

サーバーをリブートすれば復旧する。

データベースエラーが出たらまずリブート。

大体これで直る。

症例２：データベースのクラッシュ

再起動でも直らないとデータベースがクラッシュしている可能性有り。

Mysqlにログインしてみよう。

[root@ ~]# mysql -u root -p　エンターキー

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’

と出てログイン出来なかったらMySqlがクラッシュしてる可能性がある。

ログを見てみよう。

[root@ ~]# vi /var/log/mysqld.log　エンターキー

InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
131030 1:36:45 InnoDB: Assertion failure in thread 140083870848768 in file fil/fil0fil.c line 4135
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:36:45 UTC – mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

こんな感じのエラー表示がされていたら南無。

データベースが死んでます。

データベースの復旧は不可能なので、WP-DBManagerプラグインでバックアップから復元するしかない。

まずWebサーバーを止める。

Apacheなら

[root@ ~]# service httpd stop　エンターキー

それからデータベースのあるディレクトリに移動。

[root@ ~]# cd /var/lib/mysql　エンターキー

データベースを削除。

[root@ mysql]# rm -Rf データベース名　エンターキー

削除が怖かったらリネームでもいい。

復旧は出来ないと思うけど。

削除したらMySqlの再起動。

[root@ ~]# service mysqld restart　エンターキー

[ok]が出て起動したら、Mysqlにログイン。

[root@ ~]# mysql -u root -p　エンターキー

今度はソケットエラーが出ずにログイン出来るはず。

新しいデータベースを作る。

データベース名は変えること。

じゃないとエラーが出まくる。

> create database データベース名;　エンターキー

ログインユーザーの登録。

> GRANT ALL PRIVILEGES ON データベース名.* TO ユーザー名@localhost IDENTIFIED BY ‘パスワード’;　エンターキー

それからWordPressのwp-config.phpを開き、データベース名を新しいデータベース名に変更する。

define(‘DB_NAME’, ‘データベース名‘);

Apacheを起動してからダッシュボードにアクセスし、適当なログイン名とパスワードを決めてログインし、WP-DBManagerからデータベースを復旧すれば元に戻る。

非常に面倒くさい。

症例３：MySqlが起動しなくなる

Webサーバー（WordPress）がMySQLにアクセスするため、Webサーバーさえ止めてしまえばMySQLは起動するようになるはずだが、

MySQL Daemon failed to start.
mysqld を起動中:　　　　　　　　　　　　　　　[失敗]

とでて起動しない場合がある。

これもまた非常に厄介。

ログを見て症例２と同じような内容なら、データベースは粉砕されている。

まず、MySQLを起動させなくちゃならないので、mysqlデータベースディレクトリに移動。

[root@ ~]# cd /var/lib/mysql　エンターキー

3つのファイルを削除。

[root@ mysql]# rm -Rf ib_logfile0　エンターキー
[root@ mysql]# rm -Rf ib_logfile1　エンターキー
[root@ mysql]# rm -Rf ib_ibdata1　エンターキー

削除が怖かったらリネームでもいい。

それからMySQLを再起動してみよう。

[root@ ~]# service mysqld restart　エンターキー

[ok]が出て起動したら、後は症例2と同じ復旧作業を行う。

ひどい目にあった

同じデータベースエラーでも復旧方法に違いがあり、原因究明に非常に時間がかかる。

結局はバックアップから復旧の力業なんだけど、WordPressにログイン出来るようにするためのMySQL復旧作業が面倒くさい。

ブログにメモってるけど、自分のデータベースがクラッシュすると見られなくなるので意味ないし・・・ｗ

同じ症状で困っている人のためのメモって事で。