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

寫側(cè)容錯

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

恢復(fù)

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

由于事務(wù)日志由更新記錄組成，因此它允許更強(qiáng)大的索引，因?yàn)樗ㄔ谒饕恢袛鄷r重做未提交的更新。

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

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

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

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

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

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