SolrCloud 復原與寫入容錯

會為每個節點建立交易日誌，以便記錄內容或組織的每個變更。日誌用於判斷節點中應包含在副本中的內容。建立新的副本時，它會參考領導者和交易日誌，以了解要包含哪些內容。如果失敗，它會重試。

由於交易日誌包含更新記錄，因此它允許更強大的索引，因為它包括在索引中斷時重做未提交的更新。

如果領導者關閉，它可能已將請求傳送給某些副本，但未傳送給其他副本。因此，當識別出新的潛在領導者時，它會對其他副本執行同步程序。如果成功，所有內容都應保持一致，領導者會註冊為作用中，並且正常操作會繼續進行。如果副本的同步狀態過於落後，系統會要求進行完整的複製/基於重播的復原。

如果由於核心正在重新載入結構描述，而某些核心已完成但其他核心尚未完成而導致更新失敗，則領導者會告知節點更新失敗，並啟動復原程序。

當使用大於一的複寫因數時，更新請求可能會在分片領導者上成功，但在一個或多個副本上失敗。例如，考慮一個具有一個分片且複寫因數為三的集合。在這種情況下，您有一個分片領導者和兩個額外的副本。如果更新請求在領導者上成功，但在兩個副本上都失敗（無論出於何種原因），從用戶端的角度來看，更新請求仍然被視為成功。錯過更新的副本會在復原時與領導者同步。

在幕後，這表示 Solr 已經接受了僅在其中一個節點（目前的領導者）上的更新。為了讓客戶端知道這一點，Solr 會在回應標頭中包含「已達成的複製因子」(rf)。已達成的複製因子是指實際接收到更新請求的分片副本數量（包括領導者），在上述範例中為 1。如果是多分片更新請求，則已達成的複製因子是所有分片中最小的已達成的複製因子。

在客戶端方面，如果已達成的複製因子低於可接受的水平，那麼客戶端應用程式可以採取額外的措施來處理效能降低的狀態。例如，客戶端應用程式可能希望記錄在集合狀態降級時發送了哪些更新請求，然後在問題解決後重新發送這些更新。