5

今週、Solr インデックスで問題が発生しました: http://lucene.472066.n3.nabble.com/corrupted-index-in-slave-td4054769.html、

今日、そのエラーはほぼすべてのリクエストで常に発生し始め、バグだと思ったのでJIRAの問題を作成しましたhttps://issues.apache.org/jira/browse/SOLR-4707

ご覧のとおり、最終的には Solr マスター/スレーブ レプリケーションの失敗が原因でした。Solr マスター/スレーブ レプリケーションは私たちの環境に合わないように見えるため、SolrCloud への移行を検討する必要があるかどうかはわかりません。要件：

  • インデックス サイズ: ~2,000 万ドキュメント、~9GB
  • ~1200 更新/分
  • ~10000 クエリ/分 (2 つのスレーブに分散) MoreLikeThis、RealTimeGet、TermVectorComponent、SearchHandler

誰かがこれらの質問に答えるのを手伝ってくれるなら、私は感謝します:

  • SolrCloud に移行することをお勧めしますか? レプリケーションのパフォーマンスに影響はありますか?
  • その場合、どちらがより優れたパフォーマンスを発揮しますか? すべてのサーバーでインデックスのコピーを維持するか、シャード サーバーを使用しますか?
  • 高可用性を確保するには、いくつのシャードとレプリカを推奨しますか?

敬具、

ビクター

4

1 に答える 1

3

さて、すべての質問への答えは、solrcloud に正確に何を求めているかによって異なります。

  • はい、solrcloud に移行することをお勧めします。これは、高可用性、スケーラビリティ、ほぼリアルタイムの検索、および自動化されたホット レプリケーションを提供するためです。
  • 共有構成を使用して、solr がインデックス データを維持できるようにすることをお勧めします (そうすれば、TechOps の人々に笑顔をもたらすと確信しています)。これにより、人的エラーとリソース要件も削減されます。
  • 最後の質問への回答は、クラウドの展開に完全に依存します。2 シャード 2 レプリカ構成で試してから、テスト展開を作成して、それがニーズを満たすことを確認する必要があります。そうでない場合は、何が得られるまで、シャードとレプリカの数のさまざまな組み合わせを試してください。あなたが欲しい（私はその痛みを知っています！）。

最後に、将来の成長 (今後数年間でクラスターに追加するデータの量) を見積もることを忘れないでください。また、シャードとレプリカを決定する必要があることを念頭に置いてください。

于 2013-10-28T09:39:27.607 に答える