障害発生まで

• memcached(repcached)の中には揮発したらそれなりにマズい情報が入っている。
• repcachedサーバ２台のOS入れ替えをしていて、１台は再起動が成功した。
• １台目のサーバへ２台目のサーバからのレプリケーションが完了したのをstatsのcurr_itemsにて確認した。
• よって２台目を再起動するものの、起動しなくなった。

この時点では、１台は生きているから後でデータセンターいこうっと、という気軽な気持ちだった…

現象

生きている１台目のサーバで、以下のような現象が起こった…

• 値をsetする際に、ある閾値以上のexptimeを指定すると即expireされる。
• その閾値はなぜか刻々と減っていく
• memcachedでstatsコマンドを発行した結果のuptimeが4294954584とかのありえない値に
• でもdate +"%s"とかでサーバのUNIX timeチェックしてもまったく問題なし
• 俺大パニック

再起動に成功して、レプリケーションもすんだはずのサーバが謎の挙動を！
ウワーン…

tcpdumpやtelnetでプロトコルをチェックしたところ、
exptime周りの挙動がおかしいことが判明。
パニくってmemcachedの再起動とかをしてみたが状況変わらず。
exptimeを0にして仮対応した。
２台目死んだ状態で再起動したので、情報は揮発。しゅん。

死んだサーバの復旧のため、データセンターに向かう。とぼとぼと。

予想した発生メカニズム

データセンターで死んだサーバを再起動。普通に起動した…が、時間が9時間ズレている！
ということは、こんな感じで問題が起こったのかな。

• サーバのBIOS画面での時刻は、localtime(JST)になっている。
• Debianのtimezone設定はAsia/Tokyo。
• /etc/default/rcSでUTC=yesとなっていたが、NTPで時刻合わせする設定をしていたので稼働中は時刻がちゃんと設定されているように見えていた。
• /etc/init.d/memcachedでmemcached(repcached)が自動起動するようになっていた。

• 時刻が本来よりも9時間進んだ状態でサーバ起動
• memcached自動起動
• 「しばらくしてから」NTPサーバの時刻あわせが動き、時刻が9時間戻る。
• memcached大パニック

解決方法

• /etc/default/rcSでUTC=noとする
• もしくは、BIOSで設定する時間をUTCにする。

結論

• memcachedは起動後にサーバの時間が戻ると、ものっそ怪しい挙動になる。
• セッション情報は結構大事。永続化を検討すべき。特にお絵かき掲示板系はローカル保存ができない場合にはセッションが失われたらかなりマズい。
• repcachedで障害が！とTwitterでつぶやいたら即効開発者の方たちにチェックされていた。たぶん上記のような原因でした、騒いでごめんなさい…（これが主に言いたい）