SolrCloud在读取和写入中具有高度的可用性和容错性。

写侧容错

SolrCloud旨在复制文档以确保数据冗余，并使您能够将更新请求发送到群集中的任何节点。该节点将确定它是否承载适当的碎片的引线，如果不是，则会将请求转发给leader ，然后将其转发给所有现有的副本，使用版本控制确保每个副本具有最新的日期版本。如果leader 失败了，另一个副本可以取代它。这种体系结构使您可以确定，即使使用近实时搜索，也可以在发生错误时恢复数据。

恢复

为每个节点创建一个事务日志，以便记录每个对内容或组织的更改。日志用于确定节点中的哪些内容应包含在副本中。当一个新的副本被创建时，它会引用Leader和事务日志来知道要包含哪些内容。如果失败，则重试。

由于事务日志由更新记录组成，因此它允许更强大的索引，因为它包括在索引被中断时重做未提交的更新。

如果leader失败了，他们可能会向一些副本发送请求，而不是其他副本。所以当一个新的潜在leader被识别出来时，它会对其他副本运行一个同步过程。如果这是成功的，一切都应该是一致的，leader注册为主动，并且继续正常的行动。如果副本太不同步，则系统要求进行完整的基于复制/重播的恢复。

如果由于核心重新加载架构而导致更新失败，并且某些更新完成但其他更新没有完成，则leader告诉节点更新失败并启动恢复过程。

已实现的副本因子

当使用大于1的副本因子时，更新请求可能在碎片引导程序上成功，但在一个或多个副本上失败。例如，考虑具有一个分片和三个副本因子的集合。在这种情况下，您有一个分片leader和两个额外的副本。如果更新请求在leader上成功，但在两个副本上都失败，出于某种原因，从客户端的角度来看，更新请求仍被认为是成功的。错过更新的副本将在恢复时与领导同步。

在后台，这意味着Solr已经接受仅在其中一个节点（当前leader）上的更新。Solr支持更新请求上的可选min_rf参数，这些参数会导致服务器在响应中返回更新请求所达到的副本因子。对于上面描述的示例场景，如果客户端应用程序包括 min_rf >> = 1，则Solr会在Solr响应头中返回rf=1，因为请求只在leader上成功。更新请求仍将被接受，因为min_rf参数只告诉Solr客户端应用程序希望知道更新请求获得的副本因子是什么。换一种说法，min_rf 并不意味着Solr将执行最小的副本因子，因为Solr不支持回滚在副本子集上成功的更新。

在客户端，如果实现的副本因子小于可接受的级别，则客户端应用程序可以采取额外的措施来处理降级状态。例如，客户端应用程序可能希望在收集状态降级时保留发送哪些更新请求的日志，然后在问题解决后重新发送更新。简而言之，min_rf 是一个可选的机制，用于警告客户端应用程序在集合处于降级状态时接受更新请求。