SolrCloud在讀取和寫(xiě)入中具有高度的可用性和容錯(cuò)性。

寫(xiě)側(cè)容錯(cuò)

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

恢復(fù)

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

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

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

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

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

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

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

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