ElasticSearchのGatewayと記憶原理

回転:http://log.medcl.net/item/2010/10/elasticsearch-the-gateway-and-storage/
ESにはgatewayというものがあります.今日は暇を見つけて整理します.前のESを翻訳したブログは「サーチエンジンとタイムマシン」といいます.中で時間マシンに言及した以上、タイムマシンの扉を通り抜ける必要があります.(持久化したらバージョン情報を加えて、過去の未来に自由に戻せますか?)また、クラスタ全体が再起動された後、gatewayによってデータを再回復することができます.ElasticSearchは分散環境のために設計されていますので、どのようにすべてのノードのインデックス情報を永続化するかは問題です.インデックス情報以外に、CusterState(クラスタ情報)、mapping、インデックスフラグメント情報、およびtranspactionがあります. ロゴなどの情報も耐久化が必要で、0.11以降のバージョンにはLocal Gatewayが追加され、上の前のfs(共有ファイルシステムを使う)、hdfs(hadoop分散ファイルシステム)、cloud(c 2などのクラウドストレージ)が追加されます.0.11の前にデフォルトではNone、つまり耐久化を行わないとサーバがすべて切られてデータが失われます.local gatewayというパターンは、ノードがそれぞれその状態を保存しています.ノードが直接にローカルに格納してノードの状態とソース情報を回復します.localgatewayには以下のような選択肢があります.

gateway.recover_after_nodes: 1 (or gateway.recovery_after_master_nodes)
 
gateway.recover_after_time: 5m (m  、s )
 
gateway.expected_nodes: 2

これらの構成は、ノードが故障したり、クラスタが再起動したりするときには、できるだけ多くのノードが障害回復を実行することを保証し、最終的なクラスタ状態を確保し、最新のバージョンの状態情報を格納するノードがまだ起きていないかもしれません.
インデックスの回復は十分な回復の数だけでいいです.バックアップを設定していない場合、またはちょうどある破片がどうしてもなくなりました.
また、私のテストでは、2台のマシンのうち、1台はネットワークが不安定で、いつも切断されています.(ipの衝突による)クラスタ内のノードが様々な戦いをするために、ここにいくつかのパラメータがあります.

discovery.zen.fd.connect_on_network_disconnect : true
 
discovery.zen.initial_ping_timeout : 10s
 
discovery.zen.fd.ping_interval : 2s
 
discovery.zen.fd.ping_retries  : 10

共有ファイルシステムのgatewayを使用すると、デフォルトでは10 sごとにデータを非同期的に共有ファイルシステムにコピーします.(これはESの中のgateway snapshotという概念です.)もしクラスタが大きいなら、ファイルシステムを共有するには、膨大なデータ量を保存する必要があり、メンテナンス及び設備自体のコストが高いと思いますが、local方式を使えば、各ノードの自治ができます.本当に便利です.
保存について
このように長い間話しましたが、もう一つの問題はes作業の保存目録です.具体的にはesサービスのインデックス作業リストです.gatewayは持続化と回復をするだけで、直接使用しないので、もう一つの作業リストは検索操作に使います.具体的にはStoreモジュールを通じて完成しました.はい、esのストレージ設定はper indexレベルですので、各indexの位置を指定してもいいです.長期化された作業が終わった以上、ローカル操作のインデックスは普通は二つの場所にしか置いていません.メモリとローカルファイルシステムは主に性能的に考慮されています.メモリが大きいなら、全部メモリを入れます.ディレクトリの下(またはメモリ)のものは、失われたものと一時的なものとを仮定して、また複数のコピーが異なるノードに保存されています.各インデックスはまた複数の破片に分解されて、異なるノードに位置しています.ノード上のデータがなくなったと仮定しても、インデックス全体がその中の一つのかけらのコピーをなくしただけです.(allocate)データの完全性を確保する.
もう一つの重要な特徴はesが直接jvmheap以外のメモリを使うことです.以下はinexを使ってメモリを使って記憶する構成例です.

index :
    store:
        fs:
            memory:
                enabled: true

もう一つはインデックスのデフラグ数とコピー数の配置についてです.既存のインデックスにデフラグ数を修正することはできません.つまりデータがあると修正できません.現在はesは簡単なハッシュモダリティだけです.今後は一貫性のあるハッシュをサポートすればいいですが、コピーの数はいつでも動的に変更できます.グローバルに設定するなら、下記を参照してください.

gateway:
    type: local
index:
    gateawy:
        snapshot_interval: 30s
    number_of_shards: 3
    number_of_replicas: 2
path:
    logs: /path/to/logs

インデックスを新規作成して設定します.PUThttp://localhost:9200/myindex/

{
 "index" : {
 "number_of_replicas" :3,
"number_of_shards" :7
 }
 }

動的設定インデックスコピー数:PUT:http://localhost:9200/myindex/_settings

{
 "index" : {
 "numberOfReplicas" :2
 }
 }