SolrCloud 恢复和写入容错

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

由于事务日志包含更新记录，因此它可以实现更强大的索引，因为它包括在索引中断时重做未提交的更新。

如果领导者宕机，它可能已将请求发送到某些副本而没有发送到其他副本。因此，当识别出新的潜在领导者时，它会对其他副本运行同步过程。如果成功，一切都应该保持一致，领导者注册为活动状态，并且正常操作继续进行。如果副本的同步状态太差，系统会要求进行完全复制/基于重放的恢复。

如果因为内核正在重新加载模式而导致更新失败，且部分内核已完成加载而其他内核尚未完成，则主节点会告知其他节点更新失败并启动恢复过程。

当使用大于 1 的复制因子时，更新请求可能在分片主节点上成功，但在一个或多个副本上失败。例如，考虑一个具有一个分片和复制因子为 3 的集合。在这种情况下，您有一个分片主节点和两个额外的副本。如果更新请求在主节点上成功，但在两个副本上都失败（无论出于何种原因），则从客户端的角度来看，该更新请求仍被认为是成功的。错过更新的副本将在恢复时与主节点同步。

在幕后，这意味着 Solr 已接受仅存在于其中一个节点（当前主节点）上的更新。为了使客户端了解这一点，Solr 在响应头中包含“已达到的复制因子”(rf)。已达到的复制因子是实际接收到更新请求的分片副本数量（包括主节点），在上述示例中为 1。在多分片更新请求的情况下，已达到的复制因子是所有分片中最小的已达到复制因子。

在客户端，如果已达到的复制因子小于可接受的水平，则客户端应用程序可以采取额外的措施来处理降级状态。例如，客户端应用程序可能想要记录在集合状态降级时发送了哪些更新请求，然后在问题解决后重新发送这些更新。