21

誰かが彼の最高の「ホットバックアップ」戦略を共有できれば面白いでしょうElasticSearch。

また、この問題に関連するツールやライブラリを自由に共有してください。

更新： @javannaからの回答に感謝します。これは非常に完全であり、今後のアクションに適した方向性を提供します。

私はまた、小さな調査を行い、誰かが興味を持っている場合に役立ついくつかの記事/ディスカッションを見つけました。

更新： Elasticsearch 1.0には「公式」バックアップソリューション（Snapshot / Restore API）があり、これが現在の唯一の正しい方法です。ElasticSearchはマスターシャードを識別し、一貫性に注意を払います。バックアップは段階的に実行されるため、非常に高速かつ何度でも実行できます。

4

2 に答える 2

8

レプリカは一種のバックアップであり、elasticsearchは元のプライマリシャードと同じノードにレプリカを割り当てることはありません。ただし、クラスター内にあるシャード、レプリカ、ノードの数によっては、データが失われるリスクがあります。

インデックスとクラスターメタデータを保存できるゲートウェイモジュールを見てみましょう。ゲートウェイにはさまざまな種類があります。たとえば、すべてのノード間で共有されるファイルシステムにインデックスとメタデータをコピーできる共有FSを見てみましょう。ゲートウェイスナップショットAPIを使用してスナップショットを手動で開始することもできます。

また、index.translog.disable_flushインデックス設定でフラッシュを無効にすると、（すべてのノードで）データディレクトリのコピーを作成できます。そうすれば、コピー中にluceneコミットが発行されないようにすることができます。コピーを作成したら、フラッシュを再度有効にする必要があります。

アップデート

ローカルのものを除くすべてのゲートウェイタイプは非推奨になり、将来のバージョンで削除される予定です。Elasticsearch 1.0は、より優れたバックアップソリューションとともにリリースされます。

于 2012-10-12T17:35:37.757 に答える
-4

したがって、これはElasticSearchの動作に反しますが、お互いを認識しない2つの別個のElasticSearchインスタンスを用意することを検討します。アプリコードでは、すべてのコマンドが両方のインスタンスに送信されます。コマンドが1つのインスタンスで失敗した場合は、1分後にそのコマンドを再試行し、再試行を続けます。これで、インスタンスの1つをホットバックアップとして保持できます。または、2つのインスタンス間でクエリの負荷を分散することにより、パフォーマンスを向上させるために使用することもできます。

ElasticSearchでレプリカを設定するのが好きではない理由は、どのノードがどのレプリカを取得するかを構成するのが面倒であり、将来組織を再配置する場合は、基本的に大量の作業を行う必要があるためです。ElasticSearchは舞台裏で大量のリバランスを行い、すべてをあなたに代わって実行しようとします。強力なサーバーがあり、何が何を取得するかを気にしない場合は、これは良いことですが、そうでない場合は苦痛になる可能性があります。

于 2013-11-01T23:37:17.680 に答える