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

WordPress


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

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

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

自鯖も考え物だね。

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



症例1:アクセス過多


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

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

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

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

大体これで直る。



症例2:データベースのクラッシュ


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

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からデータベースを復旧すれば元に戻る。

非常に面倒くさい。



症例3:MySqlが起動しなくなる


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


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


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

これもまた非常に厄介。

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

まず、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復旧作業が面倒くさい。

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

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


WordPressのデータベース接続エラーについて」への12件のフィードバック

    1. 葛葉 キョウジ(管理人) 投稿作成者

      MySQLは3.5.1、WordPressは3.6.1です。
      クラッシュはしないバージョンのはずなんですけどね・・・

      返信
  1. 携帯乞食 きんちゃん

    http://ja.wordpress.org/

    によると

    WordPress 日本語版バージョン 3.2〜3.6 の動作環境
    PHP バージョン 5.2.4 以上
    MySQL バージョン 5.0 以上

    です。

    また、mysql ですが、現在は最新版は 5.6.14 です。
    mysql 3.5.1 ってずいぶん古いですね。
    また、私の知識が正しければ 3.2.3 が mysql 3 の
    最終安定版だったと思います。(間違っていたらすみません)

    いずれにせよ、mysql を 5.0 以上の安定版に上げるのが
    良さそうに思えます。

    返信
    1. 葛葉 キョウジ(管理人) 投稿作成者

      MySQL5.6.1でした。見間違えてましたw
      定期的にyum update でバージョンアップしてるんですけどね・・・。

      返信
      1. 携帯乞食 きんちゃん

        http://dev.mysql.com/doc/relnotes/mysql/5.6/en/

        によると 5.6.7 までは既知の問題があるバージョンみたいですので、新しければよいって訳ではありませんが、最新版を試してみる価値はあると思います。
        または、5.6.8 以降。

        1日1万アクセス程度なら他の負荷が高くなければ、VPS でも問題ないと思います。

        返信
        1. 葛葉 キョウジ(管理人) 投稿作成者

          なるほど。詳しくありがとうございます。
          バージョンアップして様子を見てみることにします。

          返信
  2. syuu

    VPSではswap管理があいまいなところがあります。
    アクセス数が増えメモリー不足になっていませんか?

    返信
    1. 葛葉 キョウジ(管理人) 投稿作成者

      2Gだと1日1万アクセスは耐えられないんですかね・・・。
      いきなり猛烈なトラフィックがあった後ダウンしてるみたいです。

      返信
    1. 葛葉 キョウジ(管理人) 投稿作成者

      おお、ちょっと調べてみます。
      ありがとうございます。

      返信
      1. oshima

        Movable Type(MT)は重いPerl CGIなので共用サーバで動かすのは辛いですが、サーバ環境の自由がきくVPSなら普通に使えます。

        こちらと同じさくらのVPS 2Gにて、自分のブログを以下のリバースプロキシ形式で運用してます。

        apache → starman(Perl製Webサーバ) → MT

        実行に必要なPerlモジュールのインストールが面倒ですが、そこをクリアすればCGIとして動かすのは簡単です。

        役に立ちそうな検索キーワード:PSGI、starman(ノイズを減らすためにperl付きで)、cpanm、cpan

        返信
        1. 葛葉 キョウジ(管理人) 投稿作成者

          おお、ありがとうございます。
          早速調べてみます。

          返信

syuu へ返信する コメントをキャンセル

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)