さくらインターネットでWordPressごとにデータベースを分ける方法

Pocket

さくらインターネットのスタンダードプランでは現在、MySQLデータベースを合計20個まで作成可能ということで、一つのデータベースを参照している複数のWordPressの向け先を分けることにしました。その方法を書いておきたいと思います。

Wordpress自体にもエクスポート機能はありますが、これはプラグインによって生成されたテーブルまではエクスポートしてくれません。基本的な記事データのみです。例えば、アクセスログを取るようなプラグインを入れていた場合、そのデータは引き継がれません。一度プラグインを停止させ、再び有効化することでテーブルは作成されるでしょうが、データはまっさらになってしまいます。


なので今回はwordpressのエクスポート機能は使わずに、phpMyAdminのエクスポート機能を使う方法をご紹介します。この方法ならプラグインのデータもそのまま移動出来て手間も省けます。


スポンサードリンク


ちょっと余談。長いのでさっさと本題に入りたい方はここからジャンプ!



確か、自分が契約した時はデータベースは一つしか作れなかったんですよね。
負荷が高くなってきたのか503エラーが多発しているので、少しでも負荷を分散させるべくデータベースだけでも分けることにしました。

実は503エラー多発は今に始まったことでは無くて、ITめもりーにょの記事にはしていませんでしたが、さくらインターネットのサポートとのやり取りが何度かありました。

コントロールパネルに出てくる「プログラムの過負荷により、CGI/PHPが制限されています。」ってやつですね。蛇足ですが、その際にこんな質問を投げてみました。あまりにも表現が抽象的なテンプレ回答だったもので。


似た件でググると良く出てくるテンプレ回答「同時実行数」の定義について質問。

「同時実行数」とは、次のうちどの認識が正しいでしょうか?
1.「同一プロセス名」が同時に実行される数
  →同じプログラムでもプロセス名を変更すれば「同時」と見なされない?
2.(プロセス名は関係なく)プロセスが同時に実行される数
  →例えばどんなに低負荷なプログラムでも、「規定の数」を超えたら制限されてしまうのでしょうか?
3.プロセス数は関係なく、CPUやメモリ等のリソース消費量を差している?
  →そうなら「同時実行数」という文言は正確ではないのでは?

「同時実行数」の定義が不明瞭では、効力ある改善が行い辛いため今回質問させて頂いた次第です。


で、さくらインターネットからの回答。

同時接続数につきましては、ご記載いただきました「2」が該当する
ものとなります。


まぁ実際は1も2も3も考慮されているんだと思ってますけどね。
というか3って認識じゃなくて良いの?さくらインターネットさん?(´・ω・`)

まぁ、どうしても「同時実行数」の「数」って言葉が気になったものでw
だって、負荷を掛けるのって大抵の場合「数」ではなくてリソース消費「量」じゃないですか?
メモリ消費量だったりCPU消費量だったり。そういうのって実行数とは呼ばないでしょ・・・。



余談終わり。掲題の話題に戻ります。




本当はsshでログインしてシェルで済ますのがスマートなのでしょうが、今回はphpMyAdminを使用します。

データベースを分ける前の状況

  • データベース1
  • wordpress1
  • wordpress2
  • …(略)


データベースを分けた後のイメージ

  • データベース1
  • wordpress1

  • データベース2
  • wordpress2

  • データベース…
  • wordpress…


手順1.データベース2の新規作成

コントロールパネル>データベースの設定ページに「データベースの新規作成」というリンクがあるのでクリック!
「データベース名」はこの場ではwordpress2としますがお好みで。
「パスワード」は適当に。
「データベース文字コード」はUTF-8にしましょう。


手順2.データベース1から移動させるwordpress2のテーブルをエクスポート

  1. データベース1(既存のデータベース)のphpMyAdminにログインし、使用しているデータベースを選択。テーブルの一覧が出てきますが、データーベース名を選択したままウィンドウ右タブにある「エクスポート」をクリック。
  2. 「DB のダンプ(スキーマ)表示」>「エクスポート」から、移動させるwordpressの接頭語のついた全テーブルを選択。(おそらくwp_wordpress1_、wp_wordpress2_みたいに分けているはず)今回の例では”wp_wordpress2_”を接頭語に持つ全テーブルを選択。
  3. 「ファイルに保存する」>「圧縮」で「gzip」を選択
  4. 他はデフォルトのまま、画面下部にある「実行」ボタンを押下。ファイルとしてローカルに保存します。

注釈:「オプション」>「構造」>「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT を追加」にチェックを入れると、エクスポートと同時にテーブルごとデータも消してくれます。一見便利なのですが、エクスポートするデータ量が多いと、次の手順でインポートする際にタイムアウトエラーになります。最悪、データの復元が難しくなるケースもありそうなので、インポートが終了するまでは元のデータは残しておきましょう。


手順3.データベース2に手順2でエクスポートしたwordpress2データをインポート

  1. 手順1で作成したデータベース2のphpMyAdminにログインし、データベース2を選択
  2. ウィンドウ右タブにある「インポート」をクリック。
  3. 「インポートするファイル」>「参照」で、手順2でエクスポートしたgzipを選択

注釈:タイムアウトしてしまう場合は手順2に戻り、2で選択するテーブルを適度に分割しましょう。回線速度や時間帯にもよると思いますが、自分の場合はgzipファイルの21MBでタイムアウト。大体10MBずつになるようにして再度インポートしたところOKでした。

もし手順2の注釈に書いてある「DROP TABLE」を選択していたら、たぶんファイルを目視チェックしながら分割するハメになっていたと思います・・・。


手順4.wordpress2のwp-config.phpの編集

修正する箇所は以下の3点。
  • DB_NAME:手順1で入力した「データベース名」
  • DB_PASSWORD:手順1で入力した「パスワード」
  • DB_HOST:コントロールパネル>データベースの設定に表示されている、「mysql[数字].db.sakura.ne.jp」形式のアドレス

DB_USERは変わってないはずです。


手順5.動作確認と旧テーブルの削除

  1. 今まで通り表示されれば成功!試しに一つ記事を書いてみましょう。
  2. 旧データベースのphpMyAdminからwp_wordpress2_postsテーブルを参照し、先ほど書いた記事データがinsertされていないことを確認。
  3. 同様に、新データベースのwp_wordpress2_postsテーブルに記事データがinsertされていることを確認
  4. ここまで確認できたら旧データベースの接頭語「wp_wordpress2_」のテーブルを全てdrop tableしちゃいましょう。心配なら残しておきましょう。


まぁ、何か問題が起きたらwp-config.phpの設定を元に戻せば良いだけですし、しばらくは旧データベースのテーブルも残しておくことをお勧めします。




お役に立てましたか?

ブックマークをどうぞ!

スポンサード リンク

コメントを残す