初期モード= "LAZY/EAGER"でハゼルキャストパーティションが動作しなくなった

Question

initial-mode = "LAZY/EAGER"パーティションが失われたときに動作するのでしょうか。

オンラインドキュメント によると、EAGER - 同期的にエントリを読み込みます。別のノード

でのバックアップがある場合にGetMapリクエストの呼び出しは（）これは私が失われたパーティションは次のシナリオにロードされている方法を知っておく必要があり

...

1）ノードのクラッシュを発生した一方でブロックされ、パーティションを失っています

• DBまたはバックアップからロードされたパーティションデータが失われますか？
• DBからロードされている場合、初期モード= "LAZY/EAGER"がマップ にどのように影響しますか？
• その紛失したパーティションは、 バックアップが利用可能なノードに移行するか、完全に 新しいノードに移行することはできますか？

2）ノードがクラッシュすると、DB

どのように初期モード= "LAZYからロードされます別のノードこのシナリオで失われたパーティションのデータで

• には、すべてのバックアップがない場合、パーティションを失いました/ EAGER "はバックアップがない場合にマップの読み込みに影響しますか？即座

ときの初期モード=「LAZY」、 パーティションが失われた後、私はそれが別のノードに再配置見ることができ、私はそれがデータ

を持つ唯一のパーティションの作成はないと思いますこのイメージでは、パーティションID 87が失われていて、直ちにパーティションサマリーが別のノードに再配置されたことを示すことができます。

62-（LOM：FE44） = partionID - （パーティションキー）

Answer 1

まず、バックアップオプションの基本的な違いを理解することから始めることができます： 同期 - 私たちはので強い一貫性を持っているデフォルトでは、デフォルト0 [非同期バックアップカウント]

- デフォルト1 [バックアップカウント] 非同期に： クライアントmap.put（foo） - >プライマリ2つのスレッド：プライマリのパーティションにT1操作スレッドを格納し、T2をバックアップに保存します。クライアントに返す前にT1とT2の結合。したがって、map.putからの戻りが発生すると、データは2つの場所に安全に格納されます。

[backup-count]を0に設定して[async-backup-count]を0に設定した場合、クライアントに返す前にT1とT2がではないため、に参加できなくなります。 T1が終了すると、サーバーはクライアントに戻ります。

1）ノードがクラッシュし、別のノードにバックアップがあると失われたパーティション そのパーティションのデータがDBまたはバックアップからロードされますか？ MapStore（データベースにデータを格納するいくつかの方法の1つです）については説明していませんが、マップストアを実装していれば、キャッシュミスが発生した場合にそこから復元されます。

DBからロードされている場合、initial-mode = "LAZY/EAGER"はマップの読み込みにどのように影響しますか？ Lazyは、完全なマップ（データの271/271番目）をロードするEagerと比較して、パーティションデータ（デフォルトではデータの271分の1）をロードします。

失われたパーティションは、完全に新しいノードに移行することは可能ですか？ バックアップはすぐに失われたサーバーからパーティションを復元します。現在プライマリになっているバックアップは、新しいバックアップを要求します。

2）別のノードにバックアップがない場合のノードのクラッシュと紛失したパーティション [backup-count]と[async-backup-count]とMapStoreの設定に失敗し、HotRestartを使用していない場合データを失った。しかし、このような状況を作り出すためには、デフォルトを変更しなければなりませんでした。

このシナリオでは、失われたパーティションデータはDBからロードされます バックアップがない場合、initial-mode = "LAZY/EAGER"がマップのロードにどのように影響しますか？ この場合も、マップデータがどれだけロードされるかが決まります。マップストアがある場合は、DB上で呼び出されるロード（キー）の数を意味します。

希望すると、