Elasticsearch のドキュメントによると、write_consistency レベルのクォーラムのルールは次のとおりです。
定足数 (> レプリカ/2+1)
ES 0.19.10 を使用すると、16 個のシャード / 3 個のレプリカのセットアップで、16 個のプライマリ シャードと 48 個のレプリカが得られます
2 つのノードを実行すると、16 (プライマリ) + 16 (レプリカ) = 32 のアクティブなシャードがあります。
クォーラム ルールを満たすには、クォーラム > 48/2 + 1 = 25 のアクティブなシャード。
これをテストすると、3 つのノードが実行されるまで write_consistency レベルが満たされません (書き込み操作がタイムアウトします)。このセットアップでは、それぞれ 2 つのノードのグループ間でスプリットブレインを取得できるため、このような方法は理にかなっていますが、このルールがどのように機能するのかよくわかりません。ここで間違った番号を使用していますか?
プライマリ シャード数は実際には問題にならないので、N に置き換えます。
N 個のシャードと 2 つのレプリカを含むインデックスがある場合、レプリケーション グループには 3 つのシャードがあります。これは、クォーラムが 2 つであることを意味します: プライマリとレプリカの 1 つです。書き込み整合性パラメーターを満たすには、2 つのアクティブなシャード (通常は 2 つのアクティブなマシン) が必要です。
N 個のシャードと 3 個のレプリカを含むインデックスでは、レプリケーション グループに 4 個のシャード (プライマリ + 3 個のレプリカ) があるため、クォーラムは 3 です。
N 個のシャードと 1 個のレプリカを含むインデックスは特殊なケースです。これは、シャードが 2 つしかないクォーラムを実際に持つことはできないためです。レプリカが 1 つだけの場合、Elasticsearch はアクティブなシャード (プライマリなど) を 1 つしか必要としないため、設定はこの特定の配置quorumの設定と同じです。one
いくつかのメモ:
0.19 は本当に古いので、確実に、絶対に、積極的にアップグレードする必要があります。そのリリース以降に追加されたバグ修正とパフォーマンスの改善の数は数え切れません :)
書き込みの一貫性は、単なるゲートウェイ チェックです。インデックス作成リクエストを実行する前に、ノードはストロー ポーリングを実行して、write_consistency が満たされているかどうかを確認します。存在する場合は、インデックスを実行してレプリケーションをプッシュしようとします。これは、レプリカが成功することを保証するものではありません...レプリカは簡単に失敗する可能性があり、応答で確認できます。これは、一貫性の設定が満たされていない場合にインデックス作成プロセスを停止するメカニズムにすぎません。
2 つのノードを持つ「完全に複製された」セットアップは、1 つのプライマリ シャード + 1 つのレプリカです。各ノードには完全なデータ セットがあります。ES は同じデータのコピーを同じマシンに配置することを拒否するため、レプリカを増やす理由はありません (意味がなく、HA には役立ちません)。インデックスを作成できないのは、書き込みの一貫性の副作用にすぎませんが、セットアップに大きな問題があることを示しています :)