SolrCloud 恢复和写入容错

为每个节点创建一个事务日志，以便记录对内容或组织的每次更改。该日志用于确定节点中哪些内容应包含在副本中。创建新副本时，它会参考领导者和事务日志以了解要包含哪些内容。如果失败，它会重试。

由于事务日志包含更新记录，因此它允许更健壮的索引，因为它包括在索引中断时重新执行未提交的更新。

如果领导者宕机，它可能已向一些副本发送请求，但未向其他副本发送请求。因此，当识别出新的潜在领导者时，它会针对其他副本运行同步进程。如果成功，则一切都应该保持一致，领导者注册为活动，正常操作继续进行。如果副本不同步，系统会要求进行基于完全复制/重放的恢复。

如果更新失败，因为内核正在重新加载架构，并且一些内核已完成，但其他内核尚未完成，则领导者会告诉节点更新失败并启动恢复过程。

当使用大于 1 的复制因子时，更新请求可能会在分片领导者上成功，但在一个或多个副本上失败。例如，考虑一个具有一个分片和三个复制因子的集合。在这种情况下，您有一个分片领导者和两个其他副本。如果更新请求在领导者上成功，但由于某种原因在两个副本上失败，那么从客户端的角度来看，更新请求仍然被视为成功。错过更新的副本将在恢复时与领导者同步。

在后台，这意味着 Solr 接受了仅在其中一个节点（当前领导者）上的更新。为了让客户端意识到这一点，Solr 在响应头中包含“已实现复制因子”（rf）。已实现复制因子是实际收到更新请求的分片副本数（包括领导者），在上述示例中为 1。对于多分片更新请求，已实现复制因子是所有分片中已实现的最小复制因子。

在客户端，如果已实现复制因子低于可接受级别，则客户端应用程序可以采取其他措施来处理降级状态。例如，客户端应用程序可能希望记录在集合状态降级时发送了哪些更新请求，然后在问题解决后重新发送更新。