前回のデータベースのお引越し（さくら）1から作業の続きです。
内容は「WPは動かさずにデータベースのみを変更する」です。
以下作業内容詳細です。
※
一つのデータベースを二つのWPで共有してるため分割作業も入っています。
ですので通常の一つのデータベースで一つのWPを使っている場合はもっとスマートに作業できます。
前回までにエクスポートしたファイルを今度はインポートしてやります。
ネックなのはサイズの上限値だけなのでそれさえクリアすればスムーズに行く…と思うのですが、
上限値に達していなくてもサイズの大きなファイルは時間制限か何かに引っかかって
途中でエラーが起きてしまいました。
いつの間にかさくらレンタルサーバーのデータベースが1個から20個に
増量していることに気付きました。
というわけで、二つのWPで共有していた一つのデータベースを分割してみました。
作業の内容としては「WPは動かさずにデータベースのみを変更する」です。
検索するとWPをサーバーのルートディレクトリからサブディレクトリへの移動の方法とかは
ヒットするのですが、データベースの変更を扱った記事は見当たりませんでした。
まあ、作業内容が初歩的すぎるからだとは思いますが。
以下作業内容詳細です。
ロリポップの時に失敗したデータベースのバックアップの問題をまず解決することにしました。
ロリポップの時はサーバー上のmysqlパスとmysqlダンプパスがわからず使えなかったWP-DBManager。
しかしさくらではパスの位置がわかりました。
ちょっとググったら出てきました。
mysqldumpパス：
/usr/local/bin/mysqldump
mysqlパス：
/usr/local/bin/mysql
これはさくらに限っての話です。
その他のレンタルサーバーは違うのでご注意を。
自分用覚え書き的な資料ですね。
参考にしたのは病的溺愛シンドロームさん。
この設定でうまくバックアップできました。
復旧もテストしてうまくインポートできました。
よかったよかった。
ロリポではこれがどう頑張ってもできなかった。
週一の定期バックアップをメールで送信する設定もうまくいき、
ちゃんとメールに圧縮ファイルが添付されてきます。
ロリポの時はなんであんなに苦労したんだ？と思えるほどあっさりと上手くいきました。
WP-DBManagerの具体的な設置は小粋空間さんで詳しく説明していますので、是非ご一読を。
あわせて.htaccessの設定もしておくといいでしょう。
詳細は違いますが似たような状況の方もいらっしゃったようなのでご紹介。
こちらのsuzukikenichi.comさんの記事も参考になるかもしれません。
これで一通りロリポからさくらへのWPの引っ越しは終了。
以前よりかなり快適に記事を投稿できるようになりました。
同じものを使っていてもレンタルサーバーが違うだけでここまで違うとは
少々驚愕しております。
これからWPを使おうかな、と思っている方がいらっしゃったら参考になれば幸いです。
終わり
ロリポップ間のMySQLサーバーの引っ越しの効果がなかったので
次はいよいよレンタルサーバーの引っ越しを考えざるを得ない状況となりました。
そうなると今度は次のレンタルサーバー選びをするわけですが、
当然MySQLサーバーを使える前提条件でサーバーを探すわけです。
ロリポップより値段（263円/月）の安いサーバーは皆無のようで、
そうなるとロリポップよりもMySQLが快適でなおかつできるだけ値段が安いところ、
という方向性でサーバー選びを考えました。
かなり長い時間ネットで調べていましたが、候補は以下のものものから選んでいくことにしました。
割とメジャーなレンタルサーバーですが、あまり知名度の低いサーバーだと
評判がよくわからないので今回はスルーしました。
いずれも個人ユーザー向けの低価格サーバーです。
具体的にはHeartlogicさんのこちらの記事の比較表を大いに参考にさせていただきました。
ありがとうございます。
当初考えいていたのはヘテムル。
今まで使っていたロリポップの上位的位置づけと考えていたからです。
それをいうならチカッパもですが、カタログスペックでは値段の上昇分の性能差が
あまりないような気がしていたので、最初から除外しました。
欲しいのは容量ではなくWPを使ったときの速度と軽さ。
ハッスルサーバーはさくらやロリポの後続サーバーらしいですが、ロリポと比べてそこまで差が
ないような気がしたのこれもまた除外しました。
ロリポより安くてロリポより性能がいいとはあまり考えられないので。
それならもっと人気が出てるでしょうし。
X-serverはMTやWPを使うにはかなり評判のいいサーバーらしいですが、
ネックになるのはそのコスト。（X10の月1050円）
それでもヘテムルに比べれば安いですが。
同様にヘテムルもその値段の高さがネックになり、即決はできない状態でした。（月1500円）
最終候補に残ったのがロリポを使っていたという理由だけで同系列のヘテムルとさくらのスタンダード。
これは実際にお試し期間でその性能を実感してみることにしました。
Heartlogicさんほどはないですが、MTを使い一般的に重いとされる時間帯の21時と23時で
150件ほどの記事の再構築時間を計ってみました。
ヘテムルが
さくらスタンダードが
という結果に。
ちなみにロリポの時は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をphpMyadminでバックアップ（エクスポート）し、
復旧（インポート）するという話なのですけれど。
ひとまずlucky bugさんの記事を参考にしてバックアップ作業を開始してました。
ここで問題だったのがロリポップのMySQLではインポートの容量にに上限があるということ。
上限はどこのMySQLにもあるのでしょうけどロリポップは2MBだったような。
ちなみにさくらは8MBです。
うろ覚えですけどかなり少ない容量だった気がします。
それに対してエクスポートした私のsqlデータは28MB。
サイトの規模に不釣合いなデータサイズです。
原因はWPのアクセス解析プラグインで、MySQL上にかなり大きなサイズのテーブルが作られていました。
というわけで、私のような小規模のサイトでもアクセス解析を導入していると
上限まで簡単に到達してしまいます。
やはりMySQLをそのままインポートすることはできそうにありません。
（アクセス解析関連以外をエクスポートしてみましたが、それでも14MBもあり、やはり断念）
ロリポップの助け合い掲示板ではSQL分を適切なところで分割する、とのアドバイスがありましたが、
SQLの知識がない私ではどこから切ればいいのか皆目検討がつきません。
これはレンタルサーバー上で上限があるのではなく、操作インターフェイスであるphpMyadminで
上限を設けているのかな、 とも思い他の操作方法を模索してみました。
しかし私にはコマンドラインで操作するなどという方法はできるはずもありません。
ネット上をしばらく検索していると、IDEA*IDEAさんで紹介されていたSQL Buddyに注目。
ブラウザ上から操作してみました。
使い方はbojovs logさんの記事を参照。
エクスポートは成功。
容量は46ＭＢ?
phpMyadminでエクスポートしたデータより一回り大きい。
なぜ？WPのテーブル以外に何かあっただろうか？わかりません。
仮にこれをphpMyadmin上にて読み込むために2MBで分割していったら
単純計算で23箇所も切らなくてはならない。
それはありえない。まともに読み込めるとは思えない。
28MBだろうが46MBだろうがインポートできないことには変わりはないのでスルー。
そのままSQL Buddyでインポートできるか実験。
これは失敗。
ホワイトアウトしてしまう。
やはり容量が大きすぎるからでしょうか。
数回試してみても一切読み込まず。
インポートはできないとの結論に。
phpMyadmin上もSQL Buddyでも容量的にインポートするのは無理なようだったので、
WPのプラグインでそういった類のものはないかと調べてみることに。
まず一番最初に使ったのがWP-DBManager。
ですが…。
WP-DBManagerを使うに当たってサーバー上のmysqlパスとmysqlダンプパスが必要なんですが、
ロリポップではそれがどこかわからずこれまた断念。
エクスポートすらできない結末。
（データベース関連はサポート外のため問い合わせるのもためらった）
次にWordPress Database Backupを使ってみました。
これはエクスポートは上手くいったのですが、インポートにこれまた5MB（うろ覚え）の上限があり断念。
（補足：sqlデータは通常サーバー上の任意のフォルダに作成されるのでFTPにローカルに保存することも可能でした）
ロリポップのMySQL間の引っ越しにあたり、データベースのバックアップは諦めました。
WPの記事データだけをバックアップして引っ越しを決断。
ロリポップのユーザー管理画面でデータベースを削除。
新たにデータベースを作成。
ここで引っ越し先のデータベースのサーバーの番号を選びます。
私の時はmysql39となぜか40が二つありました。
mysql40を選びデータベースを作成。
ダメもとでsqlデータをインポートしようとるすもやはりエラー。
潔く諦めWPをインストール。
WPをアップロード中一度もエラーが出なかったのでちょっとはマシなのか？と一瞬思いました。
続けて記事データをインポート。
一連の作業を終え、MySQLサーバーの引っ越しを完了。
これによって少しは軽くなるのかな、と思っていたら。
変わらない。
重い。
マシになったか？と思ったのは勘違いだったようです。
そもそもアップロード時にそんなにエラーでるのもおかしな話。
他に何もしていないのに。
この後もう一度データベースを削除してmysql39で同じ作業をするも結果は変わらず。
これはMysqlサーバーの引っ越しではなく、レンタルサーバーそのものを引っ越ししなければ
状況は改善されないとの結論に至りました。
次回：レンタルサーバー選びに続く
昨日、おとといと休日でしたがレンタルサーバの移転とテストで時間を潰してしまいました。
現在、データベースの引越しによるWPの再インストをしています。
ブログのxmlデータそのもののバックアップと復旧は問題ないのですが、mysqlデータベースのバックアップと復旧が上手くいかず苦戦中です。
そんなわけでやや作業途中のままブログを公開し続けるので、リンクが飛ばなかったり反応しなかったり、レイアウトがくずれたりといった不具合が起こっている可能性があります。
最終的にレンタルサーバを引っ越す場合、ここで直してもあまり意味がないのでしばらくは放置状態にしますので悪しからず。
どちらかというと引っ越す方向でテストしています。
引っ越し先のレンタルサーバのお試し期間があと1週間ほどなのと、独自ドメインの更新期間もあと10日ほどなので早めに決断、契約をしたいと思っています。
次の連休中には決めたい所です。