データの移行に伴い、phpコードの文字化けが発生している箇所があります。
＆lti や ＆gt; のような文字化けが出ているコードはコピーしないでください。
現在、手直し中です。すみません。
WP3.0 ネットワークでのデータベース保存術
WP3.0系のネットワーク機能を利用する場合、一番厄介なのがデータベースのバックアップです。
既知の通り、WP3.0系のネットワークでは、親子ブログのデータテーブルはすべて一つのMySQL上に作成されるので、子ブログを複数作成すると、データテーブルがあっという間に3桁に達します。
そうなると、MySQLをまるまる保存するのは容量的に無理がありますし、各ブログを再現するのも大変な煩雑になります。
また、バックアップ系のプラグインを使うのも、細かな部分でカスタマイズしにくいので、phpMyadminを使ってブログ単位でバックアップを取るのが一番確実です。（手動で行うのは非常に面倒くさいですが）
サイトをまるまる復元する場合は必要ないですが、サーバーを引っ越したり、新たにWordPressを開設して記事データだけインポートする場合は、wp-optionを抜かないと、以前の設定がそのまま反映されてしまうので、「管理画面に入室できない」というようなトラブルが発生します。
データのインポートに一番時間がかかるのが、記事本文を格納しているwp-postです。
容量が数MBに及ぶ場合、途中で読み込みが停止して、その他の情報までアップロードに失敗する恐れがありますので、wp-postsだけは別個にバックアップを取った方が安全です。
ネットワークを利用している場合、WPの基本テーブルの他に、サイト管理に関するテーブルが追加されます。
接頭語を「wp_」と設定した場合、
WPの基本テーブル
wp_commentmeta
wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users
サイト管理テーブル
wp_registration_log
wp_signups
wp_site
wp_sitecategories
wp_sitemeta
子ブログについては、wp_2_posts、 wp_postsのように自動生成されますので、各々についても同じ要領で、数回に分けて、バックアップを取ります。
またプラグイン関連のデータテーブルも別個にしてバックアップを取ります。
phpMyadminからバックアップする方法は、データベースとphpMyadmin バックアップとサーバー移転の手順をご参照ください。
§ wp-optionに関する注意
先にも述べたように、「wp-option」には、サイトを設置したURL、管理画面のパスワードなどが保存されていますので、たとえば新URLにサイトを復元する場合、wp-optionをそのままインポートすると、「管理画面に入室できない」「サイトが旧URLに飛んでしまう」といったトラブルが発生します。
バックアップを取る時、別個にするのは、サイト復元時に作業内容を確認するためです。
もちろん、サイトをまるまる復元する場合は、別個にする必要はありませんが、それでも別個にしておいた方が安全性は高いです。
また、wp-optionには、プラグインのデータが格納されている場合があります。
絶対にdeleteできない内容に関しては、どの部分に記載されているのか、きちんと把握しておきましょう。
たとえば、下記のデータは、「Datefeedr Random」というプラグインのものです。
Datefeedrに関するデータだけ個別にインポートする場合は、「SQL」の画面で、INSERT INTO の形でアップロードします。
行末は必ず ; で締めます。
§ バックアップを簡単にするツール
phpMyadminを使用するする場合、いちいちサーバーのコントロールパネルにアクセスするのが面倒な方は、プラグイン『Adminer』がおすすめ。
WordPressの管理画面にphpMyadminを引っ張って、同一ウィンドウ、もしくは新しいタブでアクセスすることができます。
編集や検索、クエリ、インポート・エクスポート作業など、フル機能が使えるので、データベースの直接編集をする機会が多い方には便利です。
§ 一つのデータベースに何個のデータテーブルを設置できるのか
1つのドメインに複数ブログを設置する場合、ネットワーク機能は確かに便利ですが、何十、何百ものデータテーブルが作成されてしまうのは痛いところです。
では、実質的に、いくつぐらいまで作成可能なのか。
一つの回答として、次のような質問を見つけました。
http://oshiete.goo.ne.jp/qa/2470278.html
一つのデータベース内に作成できるテーブル数に制限はあるのでしょうか？
また、テーブル数は増えれば増えるほど、一つのテーブルに1000件データが入っているテーブルと比べて、検索に時間がかかったり負荷が高くなったりするものなのでしょうか？
宜しくお願いします。
MySQLの限界ではなくて、同時アクセス数に対するサーバーそのものの限界が先に来ます
もし、正しいチューニングをしていても動作が遅くなってきたらMySQLではなくて、サーバースペックを見直してください1000レコード入ってるテーブルと10万レコード入ってるテーブル
正直言って 人間の体感的な速度に差があるようにはまったく感じません世の中には、6万テーブル、約 5億レコードのMySQLサーバーも存在しています
……ということなので、個人が複数の子ブログを運営する分にはほとんど差し支えないと思います。
もちろん、１日のアクセス数が爆発的に多くない、というのが前提ですが。
§ 『HostMonster』と『BlueHost』の場合
『HOSTMONSTER』および『BLUEHOST』の場合、サーバー上のファイルとデータベースを丸ごと保存する機能があります。
コントロールパネルの「Files」から「BackUP」をクリックし、「Download a MySQL Database Backup」からバックアップを取りたいデータベースを選んで、ローカルに保存します。
バックアップは .gz の圧縮ファイルとして生成されます。
バックアップファイルを復元する場合は、『Restore a MySQL Database』からアップロードしたいgzファイルを選択し、実行するだけです。
この機能では、「テーブルごと」といった細かな機能はなく、データベースが丸ごと保存されます。
定期的なバックアップツールとしておすすめです。
こういう機能は、日本の格安サーバーにはないので、当サイトでも上記の海外サーバーをおすすめしている所以です。
参考までに。
Ads
Leave a Reply
