コメントを書くFlareのフェイルオーバー機能をテストしてみました。(インデックスサーバにより各サーバを監視し、ダウンした場合にはサービスアウトします。Labsより今回は後半のmasterサーバーがダウンした場合のテストです。実際にダウンしてしまうというよりも、メンテナンスのためにを故意にダウンさせるケースを想定しています。実際の挙動を確認しておくことで、本番環境で自信を持ってmasterサーバーを落とすことができます。設定ファイルインストールは公式ドキュメントをご覧いただくとして、各サーバーの設定から。1台のサーバーにインデックスサーバー*1、各ノードサーバー*3を立ち上げるため、ポートを変えて起動します。設定が終わったら、各サーバーを起動します。roleコマンドで以下の状態に設定します。18通常運用では、クライアントはproxyサーバーへ接続します。その後proxyサーバーが、get時にはmaster:slave=1:2の比率(設定で変えられます)で分散してアクセスし、set時にはmasterサーバーへアクセスします。書き込まれたmasterサーバーはslaveサーバーへデータをレプリケートします。この状態で、masterサーバーを落としてみます。マスターダウンからスレーブの昇格killコマンドでmasterサーバーを落とすと、インデックスサーバーがダウンを検知し、slaveサーバーを昇格させます。18END元masterサーバがダウンしてproxyサーバーに、元slaveサーバーがmasterサーバーに昇格しています。昇格時のログログを確認すると、挙動がよく理解できます。timesインデックスサーバーは設定ファイルのmonitor-intervalの秒数ごとに各ノードへ死活チェックを行っています。今回は1(秒)に設定しているので、マスターがダウンしてから最長1秒でダウンを検知します。検知した後monitor-thresholdの回数分(3回)、死活チェックをリトライします。リトライの間は0.5秒のインターバルがあり、最後の死活チェックが終わると、ノードのダウンを決定し、新しいマスターを探します。新しいマスター候補が見つかると昇格させ、晴れてマスターになります。ログでは10秒で昇格を果たしていますが、環境やデータ量によって変わる可能性はありそうです。new_partition=-1)こちらにもインデックスサーバーの指令を受けて、マスターになるログが残っていました。クライアントへの影響マスターをダウンさせた時に接続中だったクライアントがどうなるのかを調べてみました。1〜100万をキーに20バイトの文字列をsetするプログラムで、keyの後ろの数字は処理時間を表しています。key_500268:05行目の処理時にマスターがダウンし処理が止まりますが、マスター昇格後、無事書き込みが完了しています。時間はかかるものの、書き込みは失敗しませんでした。get以下は上のプログラムでsetした値をgetするプログラムで、key:value:処理時間を表しています。key_255:01234567890123456789:06行目の処理時にマスターがダウンし処理が止まり、そのままデータが取得できず、タイムアウトしてしまいました。スレーブの台数が多ければ止まらなかったかもしれませんが、この構成では5回中5回、全て同じ結果でした。テスト不足ではありますが、getの処理は失敗することがありそうです。bootsコメントを残す(通常のコメント欄に切り換え)返信をキャンセルする。名前アカウントを持っているサービスをクリックしてください。cloudropcloudropは、クラウドコンピューティングを利用したサービスの提供・インターネットサービスの技術支援を行う会社です。