Solr7 Index Replication

Solr索引复制将主索引的完整副本分发到一个或多个从属服务器。 主服务器继续管理索引的更新。 所有查询都由从服务器处理。 这种分工使Solr能够扩展，以针对大型搜索量提供足够的响应。
下图显示了使用索引复制的Solr配置。 主服务器的索引在从属服务器上复制。

A Solr index can be replicated across multiple slave servers, which then process requests.

Index Replication in Solr

Solr包含一个通过HTTP工作的索引复制的Java实现：

• 影响复制的配置由单个文件solrconfig.xml控制
• 支持复制配置文件和索引文件
• 跨具有相同配置的平台工作
• 不依赖于依赖于操作系统的文件系统功能（例如，硬链接）
• 与Solr紧密集成; 管理页面提供对复制的每个方面的细粒度控制
• 基于Java的复制功能作为请求处理程序实现。 因此，配置复制与任何普通请求处理程序类似。

Replication In SolrCloud

尽管SolrCloud集群中没有明确的“主/从”节点概念，但SolrCloud仍然会根据需要使用此页面上讨论的ReplicationHandler来支持“分片恢复” - 但这是以对等方式完成的。
使用SolrCloud时，必须通过/replication路径提供ReplicationHandler。 除非在solrconfig.xml中显式覆盖，否则Solr会隐式执行此操作，但如果您希望覆盖默认行为，请确保您未明确设置下面提到的任何“主”或“从”配置选项，否则它们会干扰 使用正常的SolrCloud操作。

Replication Terminology

索引
Lucene索引是文件目录。这些文件构成了Solr Core的可搜索和可返回数据。
分配
将索引从主服务器复制到所有从属服务器。分发过程利用了Lucene的索引文件结构。
插入和删除
由于插入和删除发生在索引中，因此目录保持不变。文档始终插入新创建的段文件中。删除的文档不会从段文件中删除。它们在文件中被标记，可删除，并且不会从段中删除，直到该段作为正常索引更新的一部分合并。
主服务和从服务
Solr复制主机是一个单个节点，它最初接收所有更新并保持一切有条理。 Solr复制从属节点不直接接收更新，而是所有更改（例如插入，
更新，删除等）是针对单个主节点进行的。在主服务器上进行的更改将分发到所有从服务器节点，这些节点服务来自客户端的所有查询请求
更新
更新是针对单个Solr实例的单个更改请求。它可能是删除文档，添加新文档，更改文档，删除与查询匹配的所有文档等的请求。
更新在单个Solr实例中同步处理。
优化
压缩索引并合并段以提高查询性能的过程。
优化只应在主节点上运行。与在一段时间内通过许多更新变得分散的索引相比，优化的索引可以提供查询性能增益。
分配优化索引需要比将新段分配到未优化索引的时间长得多的时间。
段
索引的自包含子集，由一些文档和与这些文档中的术语的倒排索引相关的数据结构组成。
合并因子
控制索引中段数的参数。例如，当mergeFactor设置为3时，Solr将使用文档填充一个段，直到满足极限maxBufferedDocs，然后它将启动一个新段。当达到mergeFactor指定的段数时（在本例中为3），Solr会将所有段合并为一个索引文件，然后开始将新文档写入新段。
快照
包含指向索引数据文件的硬链接的目录。当从属设备拉出快照时，快照从主节点分发，“智能复制”从属节点在包含指向最新索引数据文件的硬链接的快照目录中没有的任何段。

Configuring the ReplicationHandler

除了特定于主/从角色的ReplicationHandler配置选项外，还有一些通常支持的特殊配置选项（即使使用SolrCloud时也是如此）。

• maxNumberOfBackups一个整数值，指示此节点在接收备份命令时将保留在磁盘上的最大备份数。
• 与Solr中的大多数其他请求处理程序类似，您可以在处理命令时配置一组默认值，不变量和/或附加与ReplicationHandler支持的任何请求参数相对应的参数。

Configuring the Replication RequestHandler on a Master Server

在运行复制之前，应在处理程序初始化时设置以下参数：
replicateAfter
字符串指定应在何时进行复制的操作。有效值包括提交，优化或启动。此参数可以有多个值。如果使用“startup”，如果要在将来的提交或优化时触发复制，还需要“commit”和/或“optimize”条目。
backupAfter
字符串指定应在何时执行备份的操作。有效值包括commit, optimize, 或 startup。
此参数可以有多个值。它不是复制所必需的，它只是进行备份。
maxNumberOfBackups
整数指定要保留的备份数。这可用于删除除最近N个备份之外的所有备份。
confFiles
要复制的配置文件，用逗号分隔。
commitReserveDuration
如果您的提交非常频繁且网络速度很慢，则可以调整此参数以增加传输数据所需的时间。默认值为00:00:10，即10秒。
下面的示例显示了ReplicationHandler可能的“主”配置，包括固定数量的备份和maxWriteMBPerSec请求参数的不变设置，以防止从设备使其网络接口饱和

<requestHandler name="/replication" class="solr.ReplicationHandler">
<lst name="master">
  <str name="replicateAfter">optimize</str>
  <str name="backupAfter">optimize</str>
  <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
</lst>
<int name="maxNumberOfBackups">2</int>
<str name="commitReserveDuration">00:00:10</str>
<lst name="invariants">
  <str name="maxWriteMBPerSec">16</str>
</lst>
</requestHandler>

Replicating solrconfig.xml

In the configuration file on the master server, include a line like the following:

<str name="confFiles">solrconfig_slave.xml:solrconfig.xml,x.xml,y.xml</str>

This ensures that the local configuration solrconfig_slave.xml will be saved as solrconfig.xml on the slave. All other files will be saved with their original names.
On the master server, the file name of the slave configuration file can be anything, as long as the name is correctly identified in the confFiles string; then it will be saved as whatever file name appears after the colon ':'.

Configuring the Replication RequestHandler on a Slave Server

The code below shows how to configure a ReplicationHandler on a slave.

<requestHandler name="/replication" class="solr.ReplicationHandler">
    <lst name="slave">
    <!-- fully qualified url for the replication handler of master. It is
    possible to pass on this as a request param for the fetchindex command -->
    <str name="masterUrl">http://remote_host:port/solr/core_name/replication</str>
    <!-- Interval in which the slave should poll master. Format is HH:mm:ss .
    If this is absent slave does not poll automatically.
    But a fetchindex can be triggered from the admin or the http API -->
    <str name="pollInterval">00:00:20</str>
    <!-- THE FOLLOWING PARAMETERS ARE USUALLY NOT REQUIRED-->
    <!-- To use compression while transferring the index files. The possible
    values are internal|external. If the value is 'external' make sure
    that your master Solr has the settings to honor the accept-encoding header.
    See here for details: http://wiki.apache.org/solr/SolrHttpCompression
    If it is 'internal' everything will be taken care of automatically.
    USE THIS ONLY IF YOUR BANDWIDTH IS LOW.
    THIS CAN ACTUALLY SLOWDOWN REPLICATION IN A LAN -->
    <str name="compression">internal</str>
    <!-- The following values are used when the slave connects to the master to
    download the index files. Default values implicitly set as 5000ms and
    10000ms respectively. The user DOES NOT need to specify these unless the
    bandwidth is extremely low or if there is an extremely high latency -->
    <str name="httpConnTimeout">5000</str>
    <str name="httpReadTimeout">10000</str>
    <!-- If HTTP Basic authentication is enabled on the master, then the slave
    can be configured with the following -->
    <str name="httpBasicAuthUser">username</str>
    <str name="httpBasicAuthPassword">password</str>
    </lst>
</requestHandler>

Setting Up a Repeater with the ReplicationHandler

主设备可能只能为这么多从设备提供服务而不会影响性能。一些组织已在多个数据中心部署了从属服务器。如果每个从属设备从远程数据中心下载索引，则生成的下载可能会消耗过多的网络带宽。为避免此类情况下的性能下降，您可以将一个或多个从站配置为转发器。转发器只是一个充当主设备和从设备的节点。

• 要将服务器配置为转发器，solrconfig.xml文件中的Replication requestHandler的定义必须包括主服务器和从服务器的使用文件列表。
• 确保将replicateAfter参数设置为commit，即使replicateAfter在主master上设置为optimize也是如此。这是因为在转发器（或任何从属设备）上，只有在索引之后才会调用提交
  下载。从不在从站上调用optimize命令。
• （可选）可以将转发器配置为通过压缩参数从主服务器获取压缩文件，以减少索引下载时间。
  以下是转发器的ReplicationHandler配置示例：

<requestHandler name="/replication" class="solr.ReplicationHandler">
    <lst name="master">
        <str name="replicateAfter">commit</str>
        <str name="confFiles">schema.xml,stopwords.txt,synonyms.txt</str>
    </lst>
    <lst name="slave">
        <str name="masterUrl">http://master.solr.company.com:8983/solr/core_name/replication</str>
        <str name="pollInterval">00:00:60</str>
    </lst>
</requestHandler>

Commit and Optimize Operations

在主服务器上执行提交或优化操作时，RequestHandler将读取与每个提交点关联的文件名列表。 这依赖于配置中的replicateAfter参数来确定哪些类型的事件应该触发复制。
支持这些操作：

• commit：每当对主索引执行提交时触发复制。
• optimize：每当优化主索引时触发复制。
• startup：每当主索引启动时触发复制。
  replicateAfter参数可以接受多个参数。
  例如：

<str name="replicateAfter">startup</str>
<str name="replicateAfter">commit</str>
<str name="replicateAfter">optimize</str>

Slave Replication

主节点完全没有意识到备节点。
从站持续轮询主站（取决于pollInterval参数）以检查主站的当前索引版本。如果从服务器发现主服务器具有较新版本的索引，则会启动复制过程。步骤如下：

• 从站发出filelist命令以获取文件列表。此命令返回文件的名称以及一些元数据（例如，大小，最后修改的时间戳，别名（如果有））。
• 如果从属服务器拥有本地索引中的任何文件，则会检查自己的索引。然后运行filecontent命令以下载丢失的文件。这使用自定义格式（类似于HTTP分块编码）来下载完整内容或每个文件的一部分。如果连接断开，则下载从失败点恢复。在任何时候，备节点都会尝试5次，然后完全放弃复制。
• 文件被下载到临时目录中，因此如果从站或主站在下载过程中崩溃，则不会损坏任何文件。相反，当前复制将简单地中止。
• 下载完成后，所有新文件都将移动到实时索引目录，文件的时间戳与主服务器上的时间戳相同。
• Slave的ReplicationHandler在从站上发出commit命令，并加载新索引。