【MySQL】WordPressでデータベース接続エラーが出たときの対処法
Day:2013.6.10 0:05 Comment: 0
前日、WordPressで使っているデータベースがなんの前触れもなく突然クラッシュしてブログが閲覧不能になってしまったので、その時の対処法を記事にしておきます。
ローカルにも保存しておかないとね。
ちなみにMySQLのバグだったので、MySQL単体で使っていても発生するのが恐ろしいところ。
最新バージョンのMySQLだと発生しないようなので、古いバージョンを使っている人はアップデートした方がいいです。
WordPressにログインできるならそこからバックアップデータを復旧できるけど、出来なくなってしまった時は下記の方法で対処できるかもしれない。
環境はCentOS6。
プラグインWP-DBManagerからデータを復元するものとする。
MySQLにログインできるかを確認
まず、サーバーにrootでログインし、MySQLにログインできるかを確認。
[root@ ~]# mysql -u root -p エンターキー
MySQLのログインパスワードが求められるので、ログイン。
もし、下記エラーメッセージがでてログインが出来なかった場合、データベースがクラッシュしてMySQLが強制終了してる可能性がある。
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (2)
MySQLのログを確認
/var/log/の中にあるMySQLのログを確認する。
[root@ ~]# vim /var/log/mysqld.log エンターキー
開いたら大文字のGキーを押し、ログの最下部まで移動。
ログの内容を確認。
下記のようにエラーが出ていたらデータベースが前日ブログ主がなったバグと同じ物。
数字の部分は人によって変わると思う。
130603 23:06:46 InnoDB: Page checksum 3954680317, prior-to-4.0.14-form checksum 1709741294
InnoDB: stored checksum 3954680317, prior-to-4.0.14-form stored checksum 1440116628
InnoDB: Page lsn 68 225369024, low 4 bytes of lsn at page end 238054054
InnoDB: Page number (if stored to page already) 51386,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 45515
InnoDB: (index “name” of table “データベース名“.”wp_Counterize_Referers”)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 51386.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130603 23:06:46 InnoDB: Assertion failure in thread 140509467117312 in file buf0buf.c line 3629
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:06:46 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.
赤文字の部分が記述されていた場合、ブログ主と同じバグだと思われる。
ログにも書いてはあるが、バックアップからデータベースを復旧しないとほぼ直すことは出来ない。
MySQLに詳しい人ならどうかなるかもしれないが、バックアップがあるならそこから復元した方が速い。
Apache（httpサーバー）を停止
ApacheにのっかってるWordPressがMySQLにログインを試みると即座にMySQLが強制終了してしまうため、念のためにApacheを終了させておく。
[root@ ~]# service httpd stop エンターキー
これでApacheは停止した。
データベースを隔離
適当なディレクトリを作ってそこにデータベースを隔離する。
/var/lib/mysql/内にデータベースが補完されているが、今回は/var/lib/mysql/内にmysql_bkディレクトリを作成し、そこに格納する。
まず、/var/lib/mysqlに移動。
[root@ ~]# cd /var/lib/mysql エンターキー
ディレクトリmysqlに移動した。
ディレクトリmysql_bkを作成。
[root@ ~]# mkdir mysql_bk エンターキー
これでディレクトリmysql_bkが作られた。
そこに壊れたデータベースを移動する。
[root@ ~]# mv データベース名 /var/lib/mysql/mysql_bk エンターキー
壊れたデータベースは消してしまってもかまわないと思うけど、一応移動。
MySQLの起動とデータベースの作成
MySQLを起動する。
[root@ ~]# service mysqld start エンターキー
[OK]が出てキチンと起動することを確認。
MySQLにrootでログイン。
[root@ ~]# mysql -u root -p エンターキー
無事ログインできると、
mysql>
の状態になる。
データベースを作成する。
データベース名は前と同じ物の方が手っ取り早い。
mysql> create database データベース名; エンターキー
データベースのパスワードが求められるので、前と同じものにする。
これでまっさらのデータベースが作られた。
これにバックアップデータを復元する。
最後に先ほど終了したApacheを起動する。
[root@ ~]# service httpd start エンターキー
サーバー上での操作はこれで終了。
WordPressの管理画面にログインしてWP-DBManagerを起動
管理画面にログインすると、まっさらなデータベースになっているのでブログ名やユーザー名、パスワードの入力が求められる。
ここは適当に入力して管理画面にログインし、プラグインWP-DBManagerを起動する。
他のプラグインはすべてオフになっているが、気にしない。
データの復元
WP-DBManagerを使ってデータを復元する。
左にあるメニューのデータベースをクリックし、その中のファイル操作をクリックする。
バックアップデータの一覧表が現れるので、一番新しい物を選択し、復元をクリックするとブログが復元する。
これで復元は終了。
バックアップの仕方にもよるが、すべてバックアップを取っている場合、プラグインの起動の有無まですべて復元される。
超絶オススメWP-DBManager
毎日WP-DBManagerでバックアップを取っていたおかげでスムーズにバックアップから復元することが出来た。
自動で毎日深夜にバックアップを取るようにしていたのが功を奏した。
逆に言うと、このプラグインを入れていなかったらこのブログが消滅していたと思うと恐ろしい。
VPSなどのサーバーでWordPressを運用している場合、必ずバックアップを取った方がいいよ。
出来れば毎日。
じゃないと、今回のように理不尽な理由でデータが粉砕されても誰も助けてくれない。
復元も毎日取っていればそれだけ完全に近い形でデータで復旧できる。
取っててよかったバックアップ。
