SolrCloud在讀取和寫入中具有高度的可用性和容錯性。

寫側容錯

SolrCloud旨在復制文檔以確保數(shù)據(jù)冗余，并使您能夠將更新請求發(fā)送到群集中的任何節(jié)點。該節(jié)點將確定它是否承載適當?shù)乃槠囊€，如果不是，則會將請求轉發(fā)給leader ，然后將其轉發(fā)給所有現(xiàn)有的副本，使用版本控制確保每個副本具有最新的日期版本。如果leader 失敗了，另一個副本可以取代它。這種體系結構使您可以確定，即使使用近實時搜索，也可以在發(fā)生錯誤時恢復數(shù)據(jù)。

恢復

為每個節(jié)點創(chuàng)建一個事務日志，以便記錄每個對內容或組織的更改。日志用于確定節(jié)點中的哪些內容應包含在副本中。當一個新的副本被創(chuàng)建時，它會引用Leader和事務日志來知道要包含哪些內容。如果失敗，則重試。

由于事務日志由更新記錄組成，因此它允許更強大的索引，因為它包括在索引被中斷時重做未提交的更新。

如果leader失敗了，他們可能會向一些副本發(fā)送請求，而不是其他副本。所以當一個新的潛在leader被識別出來時，它會對其他副本運行一個同步過程。如果這是成功的，一切都應該是一致的，leader注冊為主動，并且繼續(xù)正常的行動。如果副本太不同步，則系統(tǒng)要求進行完整的基于復制/重播的恢復。

如果由于核心重新加載架構而導致更新失敗，并且某些更新完成但其他更新沒有完成，則leader告訴節(jié)點更新失敗并啟動恢復過程。

已實現(xiàn)的副本因子

當使用大于1的副本因子時，更新請求可能在碎片引導程序上成功，但在一個或多個副本上失敗。例如，考慮具有一個分片和三個副本因子的集合。在這種情況下，您有一個分片leader和兩個額外的副本。如果更新請求在leader上成功，但在兩個副本上都失敗，出于某種原因，從客戶端的角度來看，更新請求仍被認為是成功的。錯過更新的副本將在恢復時與領導同步。

在后臺，這意味著Solr已經(jīng)接受僅在其中一個節(jié)點（當前l(fā)eader）上的更新。Solr支持更新請求上的可選min_rf參數(shù)，這些參數(shù)會導致服務器在響應中返回更新請求所達到的副本因子。對于上面描述的示例場景，如果客戶端應用程序包括 min_rf >> = 1，則Solr會在Solr響應頭中返回rf=1，因為請求只在leader上成功。更新請求仍將被接受，因為min_rf參數(shù)只告訴Solr客戶端應用程序希望知道更新請求獲得的副本因子是什么。換一種說法，min_rf 并不意味著Solr將執(zhí)行最小的副本因子，因為Solr不支持回滾在副本子集上成功的更新。

在客戶端，如果實現(xiàn)的副本因子小于可接受的級別，則客戶端應用程序可以采取額外的措施來處理降級狀態(tài)。例如，客戶端應用程序可能希望在收集狀態(tài)降級時保留發(fā)送哪些更新請求的日志，然后在問題解決后重新發(fā)送更新。簡而言之，min_rf 是一個可選的機制，用于警告客戶端應用程序在集合處于降級狀態(tài)時接受更新請求。