タグ: データベース

WordPressサイトのサーバー移行

この記事が見えれば新しいサーバーを参照している。リンク切れならば、もうしばらく待ってね。

さくらインターネットのVPSで動かしていたこのWordpressサイトを、同じくさくらインターネットのレンタルサーバーに移行してみた。ほとんど思いつきの行動。httpsのこれからの対応と、ちょっとVPSのサーバーでブログサイトを面倒見るのが心配だから外部に任せようと思っただけ。

移行と言っても、Wordpressのファイルとデータベースをコピーして持って来ただけ。後はデータベースを作ったり、マルチドメインの設定したり、Wordpressの設定ファイルを書き換えたりしただけ。実質1時間位の作業。hostsファイルにIPアドレスとドメインを直接書いてテストしておく。消すことを忘れずに。

トラブルと言えば、今までサクラのメールボックスでメールを受信したいたため、さくらインターネットでドメインがDNSに登録されていたので、メールボックスからドメインを削除しないとマルチドメインで登録できなかったくらい。

それとWP Super Cacheでキャッシュのクリアができないようで、再インストールした。

DNSのレコードをレンタルサーバーのほうに書き換えたので、後は待つだけ。

redirectionプラグインのせいで

お客さんから「トップページにアクセスすると、違うページが表示されるよ。」と言われた。そんなバカな、と思ったら、本当にそうだった。

そのサイトは、Wordpressで作成されたものを引き継いだもの。マルチサイトで作られている。

WordPressの設定もおかしなところもないし、リダイレクトの.htaccessのRewriteの設定も別に大丈夫。さて、わからない。

Googleさんに「wordpress リダイレクトプラグイン 勝手に」で聞いてみた。すると、Worpressのredirectionプラグインが悪さしているかも、と出てきた。

よく設定を見てみたら、redirectionプラグインを使っていた。ログを見ているとしっかりとリダイレクトしていた。データベースから直接redirectionプラグインの設定を削除したら、おかしな遷移をしなくなった。

何でそんな遷移をするようになったのだろう？ WordPress恐るべし。

redirectionプラグインを使わずに、最初からRewriteで設定すればいいのに・・・。

サイトを #AWSへサーバー切り替え

お客さんのサイトをAWSに切り替えました。しかしながら、今回が手間取りました。予行演習をして３０分でできると見積もったのに、1時間半もかかりました。

手間取ったのはデータベースサーバーの移行です。SQL Serverで動いているデータベースを、AWSのRDSのSQL Serverに移行します。これがよい方法かどうかわからないけど、メモしておきます。

直接インポートができないので、一旦ローカルのSQL Serverにバックアップ／復元をします。まずはこれではまりました。復元で最初に

既存のデータベース＊＊＊＊以外のデータベースのバックアップを保持しています。

になります。これはよくあるエラーです。こちらはオプションに上書きをチェックすると復元できるはずです。しかし復元できません。今度は

データベース＊＊＊＊はこのセッションで使用中なので、RESTORE では処理できません。

となります。これは初めてです。予行演習ではうまくいったのに。

さて、こちらの解決方法は、復元先のファイルを違う名前のファイルを指定してしまいます。本当にこの対応でいいのか？？ 今度は上手くいきました。

次は、ローカルのSQL ServerからRDSのSQL Serverにデータベースを移行します。データのインポートウィザードで一件うまく行ったと思いましたが、実際にサイトを動かしてみると、nullが格納できなかったりと、テーブル構造がキチンと移行されていません。

これは仕方ないので、AWSのRDSのSQL Server移行の基本通りに、SQLでbcpコマンドのバッチファイルを生成してしまいます。エクスポートとインポートのバッチファイルを実行して完了です。今度は上手くできました。

本番で上手くいかず、久しぶりに吐き気がするような感覚を実感しました。

今回のサービスは、3TBほどのファイルをダウンロードするサービスで、ファイルはS3に格納しています。ファイルをアップロードするだけで、とても時間がかかりました。asp.netのC#からAWSのSDKを使ってアクセス制限をしています。

#CakePHP 3を試してみました。

環境を作ってインストールできたので、CakePHP 3を試してみました。試したみたと言ったけど、簡単にいつものブログのデータベースを作って、ControllerとModelをBakeして、使用している値をダンプしてみる。あとは、CakePHP3のドキュメントを読んでみる。

つまるところ、大幅に変わったMVCのModelの部分が肝かな。ModelがTable ObjectとEntitiesになって、ORMがどう関わってくるというところが大事か。それとコントローラーとTable ObjectとEntities、ビューがどう関しているかをもっと理解しなくてはいけない。

CakePHP3のドキュメントのTable ObjectとEntitiesを訳しながら読み進めていたけど、これはおもしろぞ。

ディスクが一杯でSOS

昔のお客さんから連絡があった。サーバーのディスクが一杯で、サーバー会社から警告があって、どうしたらいいかとSOSがあった。

1年と半年前に、私がサーバーの移行をした。すっかり忘れている。Evernoteからインストールメモを引っぱり出して、サーバーにアクセスして現状を把握する。どんなことをやったかはEvernoteにメモをとっていると後で役立つ。

サーバーの中を見ていると、MySQLのバイナリログがたくさん出ていて、これがディスクを一杯にした原因。これで報告。あとはお客さんが何とかするでしょう。これ以上の作業は、お金をいただく。

Evernoteのメモによると、このサーバーはPleskというサーバー管理ソフトでWebサーバーとか、MySQLのデータベースとか、サブドメインとかを作成している。Pleskは簡単かもしれないけど、どんなことをしてくれているかわからないので。後々厄介である。メールサーバー周りの設定はいいけど、あとは自分で設定して行ったほうが逆にわかりやすいかもしれない。

一度、自分のところのPleskが動いているサーバーで、PHPのバージョンアップをしたら、二度とPleskが起動できないことをやったことがある。おかげでそのサーバーは解約した。

 追記（2014/08/08）

今サーバーを除いたら、残りが67%になって増えていた。お客さんのほうで対応したようだ。

デルのサーバー注文完了

DELLT110お客様からWindows Serverが動くPCサーバーがほしいということで、いろいろ構成を調べて見積りをとる。お客様もデルのサポートに慣れているということで、デルにお願いした。お客さんも何回かサポートを呼んでいるけど、担当者は何とかしてくれているそうだ。

今回は、Windows Serverが必須のソフトを入れるので、最初からOSが入っているPCサーバーを選定する。Windows ServerのOEM版はFoundationと呼ばれているようで、15ユーザーまで使えるらしい。今のところこのユーザー数で十分。

それとSQL Serverも使用するが、今回使用するNECのソフトをインストールするときにSQL Server Expressも自動的に一緒にインストールするらい。SQL Server Expressは

  • 1 ソケットまたは 4 コアのいずれか小さいほうに制限
  • データベースサイズ　10GB
  • メモリ　1GB

という制限があるが、こちらも最初のうちは大丈夫のようだ。制限がきつくなったら、SQL Server をStandardにすることにする。

今回は改めて、Windows ServerやSQL Serverのライセンスについて知ることができた。NECの対応者から新設にアドバイスをいただけたことは、とてもありがたかった。

デルの営業担当者には、ほしい構成を伝えて見積もってもらう。Webからでも見積りができるのだが、RAIDとか設定すると制限がわからなくなって、結局は口頭で構成を提案してもらった方が早い。こちらも、見積書を送ってもらって、それをお客さんに確認してもらい、見積書を注文書をファックスして注文完了。

折り返しデルの担当者から電話をもらって、クレジットカードの情報を口頭で伝えて、その場で支払いの認証を取ってもらって発注完了。こちらも素早い。メールでもファックスでもなく口頭でカード情報を伝えるところがアナログっぽい。電話の向こうでは担当者が端末叩いていたけど。

今回は、お客さんのほうから。直接デルに支払うのは面倒だし時間もないしということで、私のほうで立て替えることになった。入金確認も土日をはさんで時間がかかるので、さっさとカード払いにしました。

ただし、納期は3週間後だそうだ。XPからの買い換え需要で注文が殺到しているらしい。消費税が8％に上がった後でも、4月に入ってからXPサポート終了の報道を見て注文が増えているとのこと。もっと前から準備しておけば5％のときに変えたのに思う。しかしながら、見積書の消費税の項目を見たら、とても高く感じた。

さくらのレンタルサーバーで500エラー（その後）

「さくらのレンタルサーバーで500エラー」と書きましたが、さくらインターネットのサポートに電話しても、Wordpressの問題だからサポートできないと言われ、仕方ないので他のレンタルサーバーに乗り換えました。

海外のお客さんなので、Go Daddyという海外のレンタルサーバーを指定してきました。もちろんGo Daddyは初めて使います。

WordPressのサイトの移行なんて、簡単にできると思っていましたが、なかなかどうも大変でした。まずはサーバーの設定が大変でした。

FTPのアカウントが使えるようになったのが、アカウントを設定して２時間後、MySQLのデータベースを作成するのに12時間後という、何もするにも時間がかかります。sshのアカウントなんて、72時間後に利用可能ですよ。たまりません・・・・。

MySQLのデータベースの作成は、ユーザーフォーラムによると、1時間以内に作成、これ以上時間がかかる場合はサポートに連絡、とありましたので、サポートに連絡を入れておきました。これでも12時間です。

ファイルの転送も海外にサーバーがあるだけあって遅い遅い。２時間ばかり時間をかけてファイルのアップの完了です。今回はFilezillaの同時転送の機能に助けられました。

テータベースをインポートします。インポートはPHPMyAdminで行います。国内のレンタルサーバーと違って、1Gバイトまでインポート可能ですので、バックアップファイルの分割とか考えなくて済みます。

DocumentRootのパスは、コントロールパネルに表示しています（最初に見つけるのに苦労しました）。MySQLのホスト名も、コントロールパネル内に表示されています。mysqldumpは適当に、/usr/bin/mysqldump　としたら当たりました。

あとは、DNSの切り替えをして、Wordpressのサイトの移行は完了です。今度は500エラーは出ていません。さくらインターネットでのトラブルは何だったのでしょうか？

#WordPress を3.5にアップグレード

#WordPress を3.5にアップグレード

WordPress3.5の日本語版がリリースされたので、バージョンアップしました。ほんの少しの時間を待っただけで済みました。

今回は、大きなアップグレードなので慎重に対応します。マイナーなアップグレードの場合は、ボタン一発でアップグレードしていましたが、今回は念のためです。

まずはデータベースのバックアップです。あとはテーマなどの必要なファイルをバックアップを取っておきます。

つぎにブラグインをすべて無効にします。これでアップグレードの準備OKです。管理画面から行います。WordPressのアップグレードはボタンを押すだけで簡単です。

アップグレードができたら、まずはアクセスして正しくサイトが表示されるかを確認します。無事に表示されました。

次にプラグインを一つづつ有効にしながら確認です。特にキャッシュのプラグインは要注意です。

無事にアップデートができたようです。各プラグインの機能が正常に動作しているかを順次確認していきます。

Embedded Link

WordPress | 日本語 » WordPress 3.5 日本語版リリースのお知らせ
WordPress 3.5 日本語版リリースのお知らせ. 2012年12月12日, Takayuki Miyoshi. WordPress 3.5 日本語版をリリースしました。 ダウンロード: WordPress 3.5 日本語版をダウンロード. アップグレード: 「WordPress のアップグレード」を参照してください。 新機能・変更箇所: WordPress Codex 日本語版の「Vers…

Google+: View post on Google+

#WordPress でHyperDBを使ったときの運用の疑問

「#WordPress サイトの負荷分散の実験」と書きましたが、HyperDBで使ったときの運用で、その後思いついた疑問がいくつかあります。

WordPressのアップデートは自動的に実行されるか？

マスターのサーバーの管理ページでアップデートの指示がありますので、おそらくマスターサーバーだけで、スレーブサーバーはアップデートされないのでないかと思いますが。

プラグインのインストールとアップデートはどうするか？

これも、マスターだけでスレーブサーバーのプラグインは実施されないのでは？ おそらくHyperDBは、データベース関連しか面倒見てくれないので、ファイルは自分で何とかしないといけないかと思います。もっとHyperDBを調べてみる必要があります。 いずれにしても、メディアでアップデートされるファイル以外にも、/var/www/wp-content以下のファイルすべてを同期させれば解決されるのではないのか？ こちらも試してみる必要があります。

追記

プラグインのアップロードは、マスターのサーバーに限らないので、マスターとスレーブともお互いにファイルの同期を取ってあげないといけないようです。したがって、ロードバランサで管理ページは、マスターサーバーに必ずアクセスさせるようなことが必要です。以下のサイトが参考になるかな？

HyperDBでWordpressのサイトを単純に分散させても、運用で問題になりそうです。HyperDBを紹介しているサイトでそこまで言及していないのはなぜかしら？ 実際に使っていない？

#WordPress サイトの負荷分散の実験

KVMで２つ仮想サーバーを立ち上げて、Wordpressのサイトをリプリケーションして、サーバーの冗長化と負荷分散の実験してみました。

最初に1つのサーバーにWordpressをインストールして、それからKVMのクローンでサーバーをもう一つ作ってしまいます。IPアドレスを別にして2つWordpressのサイトが動く状態にします。

次に、MySQLのリプリケーションの設定をします。設定方法は、

辺りを参考にしました。Wordpressの負荷分散は、HyperDBというプラグインを使用します。これもまた、

辺りを参考に設定します。

これで、片方のサーバーのMySQLを停止してもWordpressのサイトを参照できるかを確認します。

よく考えれば当たり前なのですが、MySQLをマスターにリプリケーションに設定したほうのMySQLを停止したら、参照ができるが更新ができないようになっていました。これで成功なのです。マスターのMySQLに障害が発生したら、スレーブのMySQLからDBを復旧する手順になるのでしょう。

更新は、強制的にマスターサーバーになります。これはHypeDBの機能なのでしょう。スレーブサーバーで更新してしまったら、MySQLのリプリケーションのトラブルになってしまいます。

記事を追加したら、すぐにスレーブサーバーでも参照できるようになります。こちらはMySQLのリプリケーションが正常に動作してしているからです。

マスターとスレーブの切り替えは、DNSのラウンドロビンの機能で実現できそうです。必ず管理ページからはマスターのMySQLのデータベースに格納されるかが確認する必要がありますが、こちらはローカルにDNSを置いていないので未確認です。

以上でWordpressの二重化の実験は完了と言いたいところですが、一つ忘れていました。Wordpressのメディア機能でアップロードしたファイルは、マスターに存在することになります。スレーブのサーバーにアクセスした場合は、存在しないことになります。そこで、/var/www/wp-content/uploads/以下のファイルをマスターからスレーブサーバーに同期を取ってあげないといけません。

cronでrsyncを実行していいのですが、ここではlsyncdでサーバー間をリアルタイム（数秒の遅延はありますが）で同期を取ってしまいます。

を参考に設定しました。これでマスターとスレーブのWordpressのサイトで、アップロードされた画像が正しく参照できるを確認します。