いつも使っているサーバ環境は、基本的にAmazonのAWSなんですが、最近、使用中の一部インスタンスでリージョンの移行手順を検証してます。
移行元は”US-East”のバージニアリージョンで先は”Asia Pacific”の東京リージョン。
というのも、”US-East”で使っている一部インスタンスのAvailability ZoneのReserved Instanceが購入できなくなって、このままだと比較的割高なオンデマンドインスタンスの状態が継続してしまうためです。
同じリージョンの別のAZに移行して対処でもいいんですが、どうせならレイテンシの改善もということで、東京に逆輸入することに。
インスタンスはAMIの状態でリージョン間コピーして、EBSはrsyncでコピーしました。
そして、hostsやらhostnameやらIP書いてるconfファイルやらをざっと書き換え。
US-Eastでsmallインスタンスを立てて使ってたmemcachedサーバは、AWSのElastiCacheに移行しました。
ワクワクしながらブラウザからアクセスしてみると…
･･･お、遅い。
というか、レスポンスが数十秒しないと帰ってこない。
感覚的にはどっかで何かがタイムアウトしてる感じ。
とはいえ、ページはちゃんと表示されてます。
てことは、DBじゃなくてmemcachedか！
元環境のmemcachedはIP制限をしてるので、移行後の環境からはアクセスできずにタイムアウトになってると。
でも、コードにはそのmemcachedサーバのIPはどこにも残ってない。
新しく設定した、ElastiCacheのnodeに接続してることも確認できてる。
でも、どっかで以前のmemcachedに接続してる。
うーんうーん…
ということで、index.phpの上からechoでデバッグし始めた瞬間、
session_start();
忘れてたー！
phpのセッション管理もmemcachedにしてたのを…
php.iniのsession.save_pathを書き換えて、
;session.save_path = “tcp://123.123.123.123:11211”
session.save_path = “tcp://**.**.**.**.cache.amazonaws.com:11211”
# /etc/init.d/httpd restart
解決しましたー…orz
よく覚えときなさい > 自分
そして、東京リージョンで動くようになった状態のAMI保存&EBSスナップショットも忘れずに。