WP DBManager：DB保守で「転ばぬ先の杖」

MovabletypeからWordpress2.9に乗り換えて数ヶ月が経過したある日、突如ダッシュボードにアクセスできなくなった。ダッシュボードだけでなくWordpressで構築したサイトにもアクセスできない。しかし万が一のためにと思って残していたMTのサイトは表示されている。個々のファイル(imgとか)へのURIを入力すると表示はされる。FTPでもアクセスできる。

サーバーの障害ではなく、Wordpressの問題のようだ。

…まさかMTの呪いか？

結論だけ言ってしまうと、原因はデータベースのオーバーヘッドというやつだった。

Coreserverの管理画面からphpadminに入ってWordpressのデータベースを呼び出す。いくつかのテーブルがオーバーヘッド状態になっていた。DBの知識はほとんど持ち合わせていなかった自分は「オーバーヘッド」なんてコトバを聞いたのも初めてだったが、Google等から得た先人の知恵を拝借しこれを「最適化」してみることに。DBなんか操作してエントリーとかコメントが全部ブッ飛んじゃったらどうしよう…と不安を抱きつつ(一応「バックアップ」は取ったが実際にコンテンツが失われたらという恐怖は残るのだ)

値の入っているテーブルにチェックを入れて「最適化」。あっという間に「終了しました」のメッセージ。おそるおそるダッシュボードを開いてみると…

開けた。サイトも表示された。

この一件以来DBの状態をマメにチェックするようになったのだが、このオーバーヘッド、かなり頻発している。画面が真っ白になるような状態まで蓄積されるにはある一定の期間がかかるのだろうが放置していると早晩またそういう事態になりそうだ。いちいちphpAdmin立ち上げるのも煩わしいのでできれば自動化しておきたいところ。

で、プラグインを探してみた。WP-DBManagerというのがよく使われているようだ。
このプラグインは定期的なDBテーブルの最適化(optimize)だけでなく、DBの定期バックアップもしてくれる。

このプラグインをマルチサイト実装済みの3.0に導入してみた。「マルチ」ではあるがシステムは1つなのでDBも1つ…のはず。

管理メニューからインストール
「ネットワークで有効化」ではなく「有効化」を選ぶ
ネットワークでのDBは1つなので最適化もバックアップも1箇所からで事足りる…はず。っていうか、複数ブログから設定しようとするとハマッてしまうので。
Your backup folder MIGHT be visible to the public(バックアップフォルダが外から丸見えかもよ)と警告が表示される。

To correct this issue, move the .htaccess file from wp-content/plugins/wp-dbmanager to /virtual/goldmine/public_html/main/wp-content/backup-db
なんだそうで。
wp-content/plugins/wp-dbmanagerを開いてみると.htaccessは無くhtaccess.txtってのがある。これをwp-content/backup-dbに移動して.htaccessにリネーム。再度ダッシュボードを開くと警告が表示されなくなった
左メニューに「Database」という項目が追加される。ここで各種設定を行う。
1. Database
  現在のデータベースの状態が表示される。表示されるだけで特に設定する項目は無い。
  但しここで気をつけなければいけないのは表中の”Overhead”。このサイズが大きくなるとサイトにアクセスできなくなってしまう(画面が真っ白になる)のだ。これを後述の”Database Options”や”Optimize Database”で予防していく。
2. Backup Database
  なにやらエラーが出ている。MySQLのアドレスに関わるところだ。
  “Please Rectify The Error Highlighted In Red Before Proceeding On. (エラーを解決してからまたおいで)”と書かれているので一旦離脱する。
3. Database Options
  mysqldumpとmysqlへのパスに下記の値を入力する
  
  
  
  Path to mysqldump：　/usr/local/mysql/bin/mysqldump Path to mysql：　/usr/local/mysql/bin/mysql
  
  1
  2
  
  Path to mysqldump：　/usr/local/mysql/bin/mysqldump
  Path to mysql：　/usr/local/mysql/bin/mysql
  
  画面上部に出ている”which: no sql in ….”のエラーは気にしなくてよい(と思う)。
  画面下端の”Save Changes”を押すと”Databese option updated”と表示されて先程Backup DBで表示されていたエラーが全て解消される。
  またここにある”Automatic Scheduling”を設定するとデータベースの最適化とバックアップを一定周期で自動実行してくれる。とりあえずバックアップは2日おき、DBの最適化は半日おきに行うよう設定してみた。
  E-mail backup to:にアドレスを入れておくと./wp-content/backup-dbへのバックアップと同時にファイルをメールでも受け取ることができる。空欄にすればメールは送られてこない。
4. Backup Database (リトライ)
  ここでは手動でバックアップファイルを作ることができる。
  ページ下の “Backup” を押すと./wp-content/backup-dbにバックアップファイルが作られる。
5. Manage Backup Database
  バックアップフォルダのファイルマネージャー。
  Download(ダウンロード)、Restore(復元)、Delete(削除)の他、指定したアドレスへメールを送信することもできる。
6. Optimize Database
  データベースの最適化。手動でテーブルのオーバーヘッドを解消できる。