カテゴリー: Webデザイン関連

ロリポップ間のMySQLサーバーの引っ越しの効果がなかったので
次はいよいよレンタルサーバーの引っ越しを考えざるを得ない状況となりました。

レンタルサーバー選び

そうなると今度は次のレンタルサーバー選びをするわけですが、
当然MySQLサーバーを使える前提条件でサーバーを探すわけです。

ロリポップより値段（263円/月）の安いサーバーは皆無のようで、
そうなるとロリポップよりもMySQLが快適でなおかつできるだけ値段が安いところ、
という方向性でサーバー選びを考えました。

かなり長い時間ネットで調べていましたが、候補は以下のものものから選んでいくことにしました。

• チカッパ
• ヘテムル
• さくら/スタンダート
• X-server
• ハッスルサーバー

割とメジャーなレンタルサーバーですが、あまり知名度の低いサーバーだと
評判がよくわからないので今回はスルーしました。

いずれも個人ユーザー向けの低価格サーバーです。

具体的にはHeartlogicさんのこちらの記事の比較表を大いに参考にさせていただきました。
ありがとうございます。

当初考えいていたのはヘテムル。
今まで使っていたロリポップの上位的位置づけと考えていたからです。
それをいうならチカッパもですが、カタログスペックでは値段の上昇分の性能差が
あまりないような気がしていたので、最初から除外しました。
欲しいのは容量ではなくWPを使ったときの速度と軽さ。

ハッスルサーバーはさくらやロリポの後続サーバーらしいですが、ロリポと比べてそこまで差が
ないような気がしたのこれもまた除外しました。
ロリポより安くてロリポより性能がいいとはあまり考えられないので。
それならもっと人気が出てるでしょうし。

X-serverはMTやWPを使うにはかなり評判のいいサーバーらしいですが、
ネックになるのはそのコスト。（X10の月1050円）
それでもヘテムルに比べれば安いですが。

同様にヘテムルもその値段の高さがネックになり、即決はできない状態でした。（月1500円）

お試し期間でMTの再構築時間を計ってみた

最終候補に残ったのがロリポを使っていたという理由だけで同系列のヘテムルとさくらのスタンダード。
これは実際にお試し期間でその性能を実感してみることにしました。

Heartlogicさんほどはないですが、MTを使い一般的に重いとされる時間帯の21時と23時で
150件ほどの記事の再構築時間を計ってみました。

ヘテムルが

• 21時　1：09
• 23時　1：04

さくらスタンダードが

• 21時　1：39
• 23時　1：36

という結果に。
ちなみにロリポの時は100件ほどの記事の再構築に8分とか10分とかかかっていた（ような気がする）。

さすがにヘテムルは高いだけあってさくらよりは速いという結果に。
しかしさくらはヘテムルにくらべて1/3の値段です。（月500円）

個人的にはさくらのこの結果は必要十分と感じ、さくらのスタンダードに決定しました。
もしかしたら1000件、2000件の記事を再構築するとなると
大きく時間は変わってくるのかもしれませんが、現段階の小規模なサイトの運営上は
まったく問題ないとの結論に達しました。
値段的な問題も考慮しました。
アファリエイトをするわけでもなく、趣味でサイトを作るのに
月1500と月500では1年後、3年後ではかなり違いますからね…。

さくらレンタルサーバーのスタンダードコースに決定

というわけで、さくらのスタンダードのお試し期間中にWPを新規でインストール。
データベースの引っ越しは失敗していますが、記事データ自体は問題なくエクスポートできていたので
記事そのものは無事移植成功。

お金を払って正式契約しました。

次は同じ失敗は繰り返さないぞ！っていう意気込みでデータベースのバックアップの設定を最初に
やってしまおうというお話。

続く

ロリポのデータベースは重過ぎる

これは過去の苦労話になるのですが、以前使っていたレンタルサーバーのロリポップのお話。
低料金でいいのですが、データベース（MySQL）が非常に重くMTやWPは正直言って使えたものではありませんでした。

特にMTの重さは尋常ではなく、管理画面でメニューをワンクリックするだけで1秒以上のウエイトは当たり前。
ソースを少し編集してプレビューするだけで10秒以上かかっていました。

ほんの少し、短い記事を書いて再構築するだけで5分以上かかり、頻繁にエラーを吐き出す。

私は思いました。これは無理だと。

そういった流れで（少なくともMTより軽かった)WPを使うに至ったのですが、それでも重いという印象は変わりませんでした。

ロリポップ間のデータベースサーバー移動

契約更新の時期が迫るにつれてサーバーの引っ越しを考えるようになったのですが、
やはり面倒な話なのでなんとかならないだろうかと思い、少し検索するとUnbridled blogさんに
ロリポのMySQLサーバー移動の記事がありました。

昔のMySQLサーバーは共有している人が多めなので
新しい空いているMySQLサーバーに引っ越せば軽くなるというものです。

MySQLのバックアップ

細かい操作は端折るとして、ようはMySQLをphpMyadminでバックアップ（エクスポート）し、
復旧（インポート）するという話なのですけれど。

ひとまずlucky bugさんの記事を参考にしてバックアップ作業を開始してました。

phpMyadmin上ではインポートの容量に上限がある

ここで問題だったのがロリポップのMySQLではインポートの容量にに上限があるということ。
上限はどこのMySQLにもあるのでしょうけどロリポップは2MBだったような。
ちなみにさくらは8MBです。
うろ覚えですけどかなり少ない容量だった気がします。

それに対してエクスポートした私のsqlデータは28MB。

サイトの規模に不釣合いなデータサイズです。
原因はWPのアクセス解析プラグインで、MySQL上にかなり大きなサイズのテーブルが作られていました。

というわけで、私のような小規模のサイトでもアクセス解析を導入していると
上限まで簡単に到達してしまいます。
やはりMySQLをそのままインポートすることはできそうにありません。
（アクセス解析関連以外をエクスポートしてみましたが、それでも14MBもあり、やはり断念）

ロリポップの助け合い掲示板ではSQL分を適切なところで分割する、とのアドバイスがありましたが、
SQLの知識がない私ではどこから切ればいいのか皆目検討がつきません。

失敗（1）ブラウザ上からデータベースを操作できるSQL Buddyを使ってみる

これはレンタルサーバー上で上限があるのではなく、操作インターフェイスであるphpMyadminで
上限を設けているのかな、 とも思い他の操作方法を模索してみました。

しかし私にはコマンドラインで操作するなどという方法はできるはずもありません。
ネット上をしばらく検索していると、IDEA*IDEAさんで紹介されていたSQL Buddyに注目。

ブラウザ上から操作してみました。
使い方はbojovs logさんの記事を参照。

エクスポートは成功。
容量は46ＭＢ?
phpMyadminでエクスポートしたデータより一回り大きい。

なぜ？WPのテーブル以外に何かあっただろうか？わかりません。

仮にこれをphpMyadmin上にて読み込むために2MBで分割していったら
単純計算で23箇所も切らなくてはならない。
それはありえない。まともに読み込めるとは思えない。

28MBだろうが46MBだろうがインポートできないことには変わりはないのでスルー。

そのままSQL Buddyでインポートできるか実験。

これは失敗。
ホワイトアウトしてしまう。

やはり容量が大きすぎるからでしょうか。
数回試してみても一切読み込まず。
インポートはできないとの結論に。

失敗（2）WPのデータベース用プラグインWP-DBManagerを使ってみる

phpMyadmin上もSQL Buddyでも容量的にインポートするのは無理なようだったので、
WPのプラグインでそういった類のものはないかと調べてみることに。

まず一番最初に使ったのがWP-DBManager。
ですが…。

WP-DBManagerを使うに当たってサーバー上のmysqlパスとmysqlダンプパスが必要なんですが、
ロリポップではそれがどこかわからずこれまた断念。
エクスポートすらできない結末。
（データベース関連はサポート外のため問い合わせるのもためらった）

失敗（3）WPのデータベース用プラグインWordPress Database Backupを使ってみる

次にWordPress Database Backupを使ってみました。
これはエクスポートは上手くいったのですが、インポートにこれまた5MB（うろ覚え）の上限があり断念。
（補足：sqlデータは通常サーバー上の任意のフォルダに作成されるのでFTPにローカルに保存することも可能でした）

失敗（4）MySQLのバックアップを諦める

ロリポップのMySQL間の引っ越しにあたり、データベースのバックアップは諦めました。
WPの記事データだけをバックアップして引っ越しを決断。

ロリポップのユーザー管理画面でデータベースを削除。
新たにデータベースを作成。
ここで引っ越し先のデータベースのサーバーの番号を選びます。
私の時はmysql39となぜか40が二つありました。

mysql40を選びデータベースを作成。
ダメもとでsqlデータをインポートしようとるすもやはりエラー。

潔く諦めWPをインストール。
WPをアップロード中一度もエラーが出なかったのでちょっとはマシなのか？と一瞬思いました。

続けて記事データをインポート。

一連の作業を終え、MySQLサーバーの引っ越しを完了。

これによって少しは軽くなるのかな、と思っていたら。

変わらない。

重い。

マシになったか？と思ったのは勘違いだったようです。
そもそもアップロード時にそんなにエラーでるのもおかしな話。
他に何もしていないのに。

この後もう一度データベースを削除してmysql39で同じ作業をするも結果は変わらず。

これはMysqlサーバーの引っ越しではなく、レンタルサーバーそのものを引っ越ししなければ
状況は改善されないとの結論に至りました。

次回：レンタルサーバー選びに続く

WP2.8でStattraqが使えない状態を改善する見込みがないので諦めてちょっと浮気。
CounterizeIIというプラグインを導入してみました。

今回はwordpressの覚書さんの記事を参考にインストール作業をしました。
（特に日本語化など）
ありがとうございます。

今まで気付かなかっただけですが、このプラグインはWP公式に紹介されていたものでした。

＞リンク

どちらかというとStattraqよりはこっちの方がメジャーなのかな？

でインストール方法は他のプラグイン同様

• プラグインをダウンロード
• 解凍
• 展開されたcounterizeiiフォルダをwp-content/pluginsにアップロード
• ダッシュボードのプラグインから有効化。

インストールはこれで終了。
データベースに関連するテーブルが自動的に生成されます。

参考にさせてもらったみんなの教室さんではデフォルト（WP_）以外のデータベース接頭語を
使用する場合、 接頭語を書き換える作業をしているようでした。

私はデフォルトではない接頭語を使っていますが、特に編集せずにデータベースのテーブルが生成されました。

みんなの教室さんの使用されているバージョンがWPME2.2.3と違うからかもしれません。
現時点の日本語版WP2.8では接頭語の編集は必要なさそうです。

基本的な設定は設定一覧のCounterizeIIから、詳細な解析は投稿一覧のCounterizeIIから見ることができます。

またログインせずにサイト上でアクセス数などを見たい場合はPHPコードを
任意の場所に埋め込む方法があります。

以下引用

Today:<?php echo counterize_gethitstoday(); ?>hits and

<?php echo counterize_getuniquehitstoday(); ?> IPs<br />

Total:<?php echo counterize_getamount(); ?> hits and

<?php echo counterize_getuniqueamount(); ?> IPs

一般的にサイドバーウィジェットに埋め込む事が多いですね。

最後に設定項目画面を日本語化するにはCounterizeIIフォルダ内の

• counterize-ja_UTF.moをcounterize-ja.mo
• counterize-ja_UTF.poをcounterize-ja.po

にリネームしてアップロードすれば日本語化されます。

現在問題なく稼動しているSlimstatEXと一緒に使わせていただきます。
参考にさせてもらったサイト様に感謝します。
ありがとうございました。

とりあえず、画像を差し替えてなんとなくのサイト構築は完了。

後は使いながら細かい部分を詰めていきましょうか。

と、いいながら放置するパターンが多いのでどうなることやら。

一つサイトを移転しての感想。

同じWPを使っていてもロリポとさくらじゃ全然レスポンスが違う。

ダッシュボードでボタンを押してからの反応が体感速度で3倍くらい違います。

ちなみにさくらのスタンダードです。

データベースを使いますからね。WPは。

たくさんの先人達の言うとおり、データベースを使ったブログツールはロリポップでは使うべからず。

まあ普通のhtmlをアップして見る分には何の不満もなかったのですが。

※6/21追記

サーバー移転完了。独自ドメイン反映完了。

以前と同じアドレスで見れるようになりました。