Solr (現在は 3.5 を使用しています) を使用している場合、フェールオーバー用にマスターをセットアップするにはどうすればよいですか?
私のセットアップで、2 つのマスターと 2 つのスレーブがあるとしましょう。アプリケーションはすべての書き込みを 1 つのアクティブ マスターにコミットし、両方のスレーブがこのアクティブ マスターから更新を取得します。マスターと同じ目的を果たす別のリピーターがあります。
ここで私の質問は、何らかの理由でマスターがダウンした場合、手動の介入なしでリピーターをマスターとして作成するにはどうすればよいかということです。壊れたマスターの代わりに、スレーブがリピーターから更新を取得し始めるにはどうすればよいですか? これを行うための推奨される方法はありますか? Solr システムの高可用性を確保するために、他に推奨されるマスター/スレーブ設定はありますか?
現時点で最善の選択肢は、現在の Solr 4.0 アルファ版に存在する SolrCloud 機能を調査することです。この記事の執筆時点では、数か月以内に最終リリースが予定されています。SolrCloud の目標は、ZooKeeper 分散データベースを使用してデータ分散とマスター選出を処理し、どのノードが役割を果たしているかについてクラスター内でコンセンサスを維持することです。
Solr 3 の複製されたマスター/スレーブ アーキテクチャのフェイルオーバーを設定する従来の方法は他にもありますが、個人的にはリリース間近の Solr 4.0 にそのような投資をしたくありません。
編集：そのような従来のアプローチの1つについては、Linux-HAを参照してください。個人的には、プレゼンス検出と分散ロックに ZooKeeper を使用して、コアとロード バランサーを再構成する専用のデーモンを作成します。
アウトソーシングがオプションである場合は、私自身の謙虚なWebsolrなどのホストされたサービスを検討してください。この種の分散とホット フェイルオーバーはデフォルトで提供されているため、お客様は実装方法の仕組みについてそれほど心配する必要はありません。
私はニックに同意します。Solr 3.x でのレプリケーションの仕組みは、特にマスター フェイルオーバーの場合、常に便利とは限りません。Solr 4 を検討する場合は、elasticsearch も参照してください。これは、この種の問題を非常に素晴らしい方法で解決します!
Solr で使用されるプル メカニズムの代わりに、プッシュ レプリケーションを使用します。つまり、ドキュメントは文字通りすべてのノードで再インデックスされます。奇妙に聞こえるかもしれませんが、これによりネットワークの負荷を軽減できます (セグメントのマージなどによる)。さらに、ノードがマスターとして選出され、それがクラッシュした場合、別のノードが自動的に置き換えられ、新しいマスターになります。