在使用Solr（我們當前使用3.5）時，如何設置故障轉移的主設備？高可用性的Solr主從故障轉移設置
讓我說在我的安裝程序中我有兩個大師和兩個奴隸。應用程序將所有寫入提交給一個主動主站，並且兩個從站都從該主動主站獲取更新。還有另一箇中繼器可以達到主人的相同目的。
現在我的問題是，如果師父出於某種原因倒下了，我怎樣才能讓Repeater成爲Master而不需要任何人工干預。奴隸如何開始從中繼器獲取更新，而不是斷開的主控器。有沒有推薦的方法來做到這一點？是否還有其他建議的主/從設置來確保Solr系統的高可用性？
目前，您最好的選擇可能是調查當前Solr 4.0 alpha中的SolrCloud功能，該功能在撰寫本文時將在幾個月內發佈。 SolrCloud的目標是處理數據分配和主選舉，使用ZooKeeper分佈式數據庫在集羣內保持關於哪些節點在角色中服務的共識。
還有其他更傳統的方法來爲Solr 3的複製主從架構設置故障切換，但我個人不希望在Solr 4.0這麼接近發佈的情況下進行投資。
編輯：參見Linux-HA，用於一種這樣的傳統方法。就我個人而言，我將創建一個專門構建的守護進程，用於重新配置核心和負載平衡器，使用ZooKeeper進行狀態檢測和分佈式鎖定。
如果外包是一種選擇，您可以考慮託管服務，如我自己的謙虛Websolr。我們默認提供這種分發和熱故障轉移，因此我們的客戶不必擔心如何實施它的機制。
我同意尼克。複製在Solr 3.x中的工作方式並不總是很方便，尤其是對於主節點故障切換。如果你打算考慮Solr 4，你可能也想看看elasticsearch，它以非常出色的方式解決了這類問題！
它使用推複製而不是Solr使用的拉機制。這意味着文檔在所有節點上都被重新編制索引。這可能聽起來很奇怪，但可以減少網絡負載（例如由於段合併）。此外，一個節點被選爲主節點，如果它崩潰，另一個節點將自動替換它成爲新的主節點。
感謝Javanna的迴應！ – Ravi 2012-08-10 14:43:39
ElasticSearch是一款精心設計的+1，專門用於從頭開始分發，無需遺留代碼即可保留。在這兩種情況下（ES，SolrCloud），多主推送複製都是一個巨大的勝利。 – 2012-08-13 15:57:39
感謝您的答覆尼克。雖然我想探索Solr Cloud的選項是一種可能性，但我想知道是否有辦法用Solr 3來實現這一點，因爲我們已經在此基礎上構建了我們的框架。 – Ravi 2012-08-10 14:41:51
我的觀點的一部分是，你設定的Solr 3中自動大師選舉的任何解決方案都將比完成Solr 4更多的工作。另外，它可能會積極推遲你將來轉向Solr 4作爲沉沒成本。 – 2012-08-13 16:01:34
編輯與Solr <4. – 2012-08-13 16:13:24