クエリのw値が、生きているノード数より大きい場合

[Tetsutaro Watanabe]

渡部です。

質問させてください。

まず私の理解ですが、
rubyのクライアントなどで、クエリのwオプションを指定すると、
wの数だけのレプリカに書き込んでから、リターンが返ってくる挙動になると理解しています。
また、wオプションが、レプリカ内の生きているノード数よりも多い場合は、
いつまでたってもリターンが返ってこないという挙動になると理解しています。
（実際動かしましたがそうなります）

私の理解が正しいとして、質問です。
以下の要件を満たすアプリケーションを作る場合、どうするのがベストでしょうか？

・レプリカセットは2台のデータノードと1台のアービタ。
・通常時は2台以上に書き込み保証したいため、アプリケーションからは常にw=2 でクエリを投げる。
・データノードが1台死んだ場合は、2台への書き込みはしなくて良いので、1台だけ書き終わったらリターンしてほしい。

これを実現するには、クエリを投げる前にレプリカセットの状態を確認し、
データノードが２台とも健在ならw=2、そうでないならw=1と、
クエリを投げ変えるしかないのでしょうか？

知恵を貸していただけたら幸いです。

[Fukuzaki Akinobu]

渡部さん、お疲れさまです。
福崎です。

私自身はrubyのクライアントで当該の処理をした事がありませんが、システム設計の観点から意見を。

wオプションによる書き込みノード数制御は信頼性設計において、キーの条件となります。
何故なら、ある時点である情報がwで指定されたノード数に必ず保存されている前提（保存されて
いなければクライアントがそれを認識しており、それに対応する処置が施されている状態でもある）
を作り出してくれるため、ノードそのものの信頼性の数値を設定できれば、並列系の信頼性の値が
算出できて、稼働率などの算出ができるためです。

ですので、渡部さんが挙げておられる要件の「状況に応じて必要ノード数が変わる」というのが
そもそも信頼性の前提条件どおしでカニバリをしてしまい、結果的に低い信頼性のほうにシステムを
よせてしまっていると思います。

ですので、要件の整理が必要と考えます。

A案、アービタがあるので常にw=2と考える
B案、実はそこまで信頼性が高い必要は無いのでw=1と考える

AとBとでは信頼性は大きく異なりますが、B案で算出された信頼性で十分なシステム要件ならば
B案でも問題無いのです。

ただ、

http://docs.mongodb.org/manual/core/replica-set-write-concern/

を見て見たところ、タイムアウトってのもあるので、

C案、データノードが片肺の時は若干レスポンスが悪くなるがw=2で常に投げる（タイムアウト設定付きで）

って案も出てきます。
ただ、これは信頼性設計の観点では意味が無く、かつレスポンスが遅くなるケースがあるため、
ユーザービリティ的にも良く無いです。（しかも、信頼性はw=1とほぼ一緒）

いかがでしょうか。

2014/01/29 1:28、Tetsutaro Watanabe <fet...@gmail.com> のメール：

> --
> このメールは Google グループのグループ「MongoDB JP」の登録者に送られています。
> このグループから退会し、メールの受信を停止するには、mongodb-jp+...@googlegroups.com にメールを送信します。
> このグループに投稿するには、mongo...@googlegroups.com にメールを送信してください。
> http://groups.google.com/group/mongodb-jp からこのグループにアクセスしてください。
> その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

------------------------------------------------------------------
Akki
Akinobu Fukuzaki

[Tetsutaro Watanabe]

渡部です。

福崎さん回答ありがとうございます。

> ですので、要件の整理が必要と考えます。

すこし伝え方が悪かったようです。もう少し要件を正確に書くと以下の通りです。

■要件
・レプリカセットは2台のデータノードと1台のアービタ。
・データを複製し、単一障害(データノード1台死亡)時でもデータロストが発生しないようにする。
・単一障害発生から復旧までの間は、データが複製されていない状態を許容する。
・単一障害発生時(フェールオーバー中)に限りレスポンスタイムの悪化は許容するが、その後(1台による縮退運用時)はレスポンスタイムは元に戻る必要がある

実は、この要件はMySQLの準同期レプリケーションを使うと達成できます。
　準同期レプリケーションは必ず２ノード以上にデータの存在を保証します(w=2と同じ)が、
　レプリケーション先が障害になった場合は、自動的に非同期レプリケーションにモード(w=1と同じ)に変わります。

それと同じことがMongoDBでできないかと考えています。

> A案、アービタがあるので常にw=2と考える
→アービターはレプリケーションの対象ではないので、その考え方はできないと思います。

> B案、実はそこまで信頼性が高い必要は無いのでw=1と考える
→いえ、上記の通りの信頼性が必要です。

> C案、データノードが片肺の時は若干レスポンスが悪くなるがw=2で常に投げる（タイムアウト設定付きで）
→これはレスポンスタイムに関する要件を満たせないのでだめですね。。。



2014年1月29日 7:50 Fukuzaki Akinobu <akki.t...@gmail.com>:

[Fukuzaki Akinobu]

渡部さん、お疲れさまです。
福崎です。

なるほど。

要件としては
・二重障害発生時は全損あるいはアービタに残っている状態への巻き戻しを許容
・二重障害は発生しない前提（と出来るくらい復旧時間が短い？）
のどちらかが入ると思ってよろしいでしょうか。

その前提で話を進めると、

w=1で満たせないケースは
・マスターからスレーブにレプリケーションできる前にマスターが壊れるケース
が問題になりますね。

うーーん、C案でタイムアウトをずっと短くするじゃだめですかね？


===============================
Akinobu Fukuzaki



2014/01/29 10:26、Tetsutaro Watanabe <fet...@gmail.com> のメール：

[Hiroaki Kubota]

窪田です。

それは無理ですね。

何度か同じ議論が起こってますが、writeconcernはデータの保全が目的の機能で、整合性ではありません。

必ず新しいデータが欲しい場合はPrimaryから読むべきです。

2014/01/29 1:28 "Tetsutaro Watanabe" <fet...@gmail.com>:

[Hiroaki Kubota]

追記
　個人的にはアービター追加よりhiddenノードの方がオススメですね。。
　使い道が圧倒的に多いです。

2014/01/29 16:53 "Hiroaki Kubota" <cat.s...@gmail.com>:

[Tetsutaro Watanabe]

窪田さん、福崎さん

渡部です。

回答ありがとうございました。
やはり不可能ですか。
でも、MongoDBのそういうシンプルな所嫌いじゃないです。

仰る通りhiddenを作れたらよいのですが、データノードを増やすのはインパクトが大きいため、hiddenをつくるかw=1にするか検討したいと思います。

ありがとうございました。


2014年1月29日 16:55 Hiroaki Kubota <cat.s...@gmail.com>:

[Fukuzaki Akinobu]

渡部さん、窪田さん、お疲れさまです。
福崎です。

私も勉強になりました！
ありがとうございます。

2014/01/30 8:48、Tetsutaro Watanabe <fet...@gmail.com> のメール：

------------------------------------------------------------------
Akki
Akinobu Fukuzaki