用户管理索引复制

用户管理的索引复制将领导者索引的完整副本分发到一个或多个跟随者副本。领导者继续管理对索引的更新。所有查询都由跟随者处理。这种分工使 Solr 能够扩展以针对大量搜索量提供足够的响应能力。

下图显示了使用索引复制的 Solr 配置。领导者服务器的索引在跟随者上复制。

user managed replication
图 1.Solr 索引可以在多个跟随者服务器上复制，然后由这些服务器处理请求。

Solr 中的索引复制

Solr 包含通过 HTTP 工作的索引复制

  • 影响复制的配置由单个文件 solrconfig.xml 控制。

  • 支持复制配置文件和索引文件。

  • 在具有相同配置的平台上工作。

  • 不依赖于与操作系统相关的文件系统功能（例如，硬链接）。

  • 与 Solr 紧密集成；管理页面提供对复制的每个方面的细粒度控制。

  • 基于 Java 的复制功能作为请求处理程序实现。因此，配置复制类似于任何正常的请求处理程序。

SolrCloud 中的复制

虽然在 SolrCloud 集群 中没有领导者或跟随者节点的明确概念，但本页讨论的 ReplicationHandler 仍被 SolrCloud 根据需要用于支持“分片恢复”——但这以对等方式完成。

使用 SolrCloud 时，ReplicationHandler 必须通过 /replication 路径获得。Solr 会隐式执行此操作，除非在 solrconfig.xml 中明确覆盖。如果您希望覆盖默认行为，请确保不设置下面提到的任何“领导者”或“跟随者”配置选项，否则它们会干扰正常的 SolrCloud 操作。

配置 ReplicationHandler

除了下面描述的特定于领导者和跟随者角色的 ReplicationHandler 配置选项之外，还有一些通常受支持的特殊配置选项（即使在使用 SolrCloud 时也是如此）。

  • maxNumberOfBackups 一个整数值，规定此节点在收到 backup 命令时将在磁盘上保留的最大备份数。

  • 与 Solr 中的大多数其他请求处理程序类似，您可以配置一组 默认值、不变项和/或追加项 参数，这些参数与 ReplicationHandler 在 处理命令 时支持的任何请求参数相对应。

配置领导服务器

在运行复制之前，您应在处理程序初始化时设置以下参数

replicateAfter

可选

默认值：无

指定应在之后发生复制操作的字符串。有效值为

  • commit：在领导索引上执行提交后触发复制。

  • optimize：在优化领导索引后触发复制。

  • startup：在启动领导索引后触发复制。

此参数可以有多个值，如下所示

+

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

+ 如果您使用 startup，如果您希望在将来的提交或优化时触发复制，则还应具有 commit 和/或 optimize 条目。

backupAfter

可选

默认值：无

指定应在之后发生备份操作的字符串。有效值为 commit、optimize 或 startup。此参数可以有多个值。它不是复制所必需的，它只是进行备份。

maxNumberOfBackups

可选

默认值：无

指定要保留的备份数的整数。这可用于删除除最近的 N 个备份之外的所有备份。

confFiles

可选

默认值：无

要复制到从属服务器的配置文件，用逗号分隔。这些应是模式、停用词和类似配置文件等文件，这些文件可能会在领导服务器上更改，并且需要在从属服务器上更新以在提供查询时使用。

如果应复制 solrconfig.xml，则需要特别注意，以免领导服务器的配置覆盖从属服务器的配置。如下所示的行将确保本地配置 solrconfig_follower.xml 将在从属服务器上另存为 solrconfig.xml

<str name="confFiles">solrconfig_follower.xml:solrconfig.xml,managed-schema.xml,stopwords.txt</str>

在领导服务器上，从属服务器配置文件的文件名可以是任何名称，只要在 confFiles 字符串中正确识别该名称即可；然后它将另存为冒号“：”后出现的任何文件名。在上述示例中，所有其他文件都将以其原始名称保存。

commitReserveDuration

可选

默认值：00:00:10

如果您的提交非常频繁且网络速度较慢，则可以调整此参数以增加预期传输数据所需的时间。默认值为 00:00:10，即 10 秒。

以下示例显示了 ReplicationHandler 的一个可能的“领导者”配置，包括固定数量的备份和 maxWriteMBPerSec 请求参数的不变设置，以防止从属服务器使其网络接口饱和

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="leader">
    <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>

配置从属服务器

从属服务器配置需要不同于领导者，因为在这种方法中，从属服务器向领导者发起请求以获取更新的索引和其他文件。

我们使用以下参数

leaderUrl

可选

默认值：无

领导者的复制处理程序的完全限定 URL。

必须定义此参数才能从领导者获取新的索引和配置文件，但不需要在 solrconfig.xml 中定义它。它可以作为 fetchindex 命令的请求参数传递。

pollInterval

可选

默认值：无

从属服务器应轮询领导者的间隔。格式为 HH:mm:ss。如果不存在，从属服务器不会自动轮询。

如果未配置，则可以从管理 UI 或 HTTP API 触发 fetchindex。

compression

可选

默认值：无

在传输索引文件时启用压缩。可能的值为 internal 或 external。如果值为 external，请确保你的领导者 Solr 具有尊重 Accept-Encoding 标头的设置。如果将其设置为 internal，则一切都会自动处理。

虽然此参数对于一般用途来说似乎是个好主意，但通常只有在领导者和从属服务器节点之间的带宽持续较低时才需要它。

httpConnTimeout

可选

默认值：5000

等待与领导者建立连接的毫秒数。除非带宽极低或延迟极高，否则通常可以将其保留为默认值。

httpReadTimeout

可选

默认值：10000

等待读取索引文件的时间（以毫秒为单位）。与 httpConnTimeout 一样，除非带宽极低或延迟极高，否则通常可以将其保留为默认值。

httpBasicAuthUser

可选

默认值：无

如果领导者已配置 HTTP 基本身份验证，则要使用的用户名。

httpBasicAuthPassword

可选

默认值：无

如果领导者已配置 HTTP 基本身份验证，则要使用的密码。

以下示例显示了从属服务器上的 ReplicationHandler 配置

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="follower">
    <str name="leaderUrl">http://remote_host:port/solr/core_name/replication</str>
    <str name="pollInterval">00:00:20</str>

    <!-- THE FOLLOWING PARAMETERS ARE USUALLY NOT REQUIRED-->
    <str name="compression">internal</str>
    <str name="httpConnTimeout">5000</str>
    <str name="httpReadTimeout">10000</str>
    <str name="httpBasicAuthUser">username</str>
    <str name="httpBasicAuthPassword">password</str>
  </lst>
</requestHandler>

使用 ReplicationHandler 设置中继器

一个领导者可能只能服务于这么多的跟随者，而不会影响性能。一些组织已在多个数据中心部署了跟随者服务器。如果每个跟随者从远程数据中心下载索引，则下载结果可能会占用过多的网络带宽。为了避免在这种情况下出现性能下降，您可以将一个或多个跟随者配置为中继器。中继器只是一个充当领导者和跟随者的节点。

要将服务器配置为中继器，solrconfig.xml 文件中 Replication requestHandler 的定义必须包含领导者和跟随者使用的文件列表。

务必将 replicateAfter 参数设置为 commit，即使在主领导者上将 replicateAfter 设置为 optimize 也是如此。这是因为在中继器（或任何跟随者）上，只有在下载索引后才会调用提交。优化命令永远不会在跟随者上调用。

或者，可以通过 compression 参数将中继器配置为从领导者获取压缩文件，以减少索引下载时间。

以下是中继器的 ReplicationHandler 配置示例

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

复制屏幕

复制屏幕显示您已指定的核心的当前复制状态。

只有在您不在 SolrCloud 模式下运行 Solr 时才会出现此屏幕。

如果您使用领导者-跟随者索引复制，则可以使用此屏幕来

  1. 查看可复制索引状态（在领导者节点上）

  2. 查看当前复制状态（在跟随者节点上）

  3. 禁用复制（在领导者节点上）

image

跟随者复制

领导者完全不知道跟随者。

跟随者会持续轮询领导者（取决于 pollInterval 参数）以检查领导者的当前索引版本。如果跟随者发现领导者具有较新版本的索引，它将启动复制过程。

步骤如下

  • 跟随者发出 filelist 命令以获取文件列表。此命令返回文件名称以及一些元数据（例如，大小、上次修改时间戳、别名（如果有）等）。

  • 跟随者检查本地索引中是否包含任何这些文件。然后，它运行 filecontent 命令以下载丢失的文件。这使用自定义格式（类似于 HTTP 分块编码）来下载每个文件的全部内容或部分内容。如果连接中途断开，下载将从失败点恢复。在任何时候，跟随者都会尝试 5 次，然后完全放弃复制。

  • 文件下载到临时目录，因此如果跟随者或领导者在下载过程中崩溃，则不会损坏任何文件。相反，当前复制将简单地中止。

  • 下载完成后，新文件将移到实时索引目录，并且文件的时间戳与其在领导者上的对应文件相同。

  • 跟随者的 ReplicationHandler 在跟随者上发出提交命令，并且加载新索引。

复制配置文件

要复制配置文件，请使用 confFiles 参数对其进行定义。只有在领导者 Solr 实例的 conf 目录中找到的文件才会被复制。

Solr 仅在索引本身被复制时才复制配置文件。这意味着即使在领导者上更改了配置文件，该文件也仅在领导者的索引上有新的提交或优化后才会被复制。

与索引文件（其时间戳足以判断它们是否相同）不同，配置文件会根据其校验和进行比较。如果架构文件（在领导者和跟随者上）的校验和相同，则认为它们相同。

在复制配置文件时，Solr 会将配置文件复制到临时目录，然后再将其移动到 conf 目录中的最终位置，作为一种预防措施。然后，旧配置文件将被重命名并保留在同一 conf/ 目录中。ReplicationHandler 不会自动清理这些旧文件。

如果复制涉及下载至少一个配置文件，则 ReplicationHandler 会发出核心重新加载命令，而不是提交命令。

解决跟随者服务器上的损坏问题

如果向跟随者添加了文档，则跟随者将不再与其领导者同步。但是，跟随者不会采取任何措施使其同步，直到领导者有新的索引数据。

当在领导者上执行提交操作时，领导者的索引版本将与其跟随者的索引版本不同。然后，跟随者会获取文件列表，并发现领导者上存在的一些文件也存在于本地索引中，但大小和时间戳不同。这意味着领导者和跟随者具有不兼容的索引。

为了纠正此问题，跟随者会将所有索引文件从领导者复制到新索引目录，并要求核心从新目录加载新索引。

ReplicationHandler 的 HTTP API 命令

可以使用以下 HTTP 命令来控制 ReplicationHandler 的操作。

enablereplication

为其所有跟随者在“领导者”上启用复制。

http://_leader_host:port_/solr/_core_name_/replication?command=enablereplication
disablereplication

在所有跟随者上禁用领导者的复制。

http://_leader_host:port_/solr/_core_name_/replication?command=disablereplication
indexversion

返回指定领导者或跟随者上最新可复制索引的版本。

V1 API

http://_host:port_/solr/_core_name_/replication?command=indexversion

V2 API

http://_host:port_/api/cores/_core_name_/replication/indexversion
fetchindex

强制指定的跟随者从其领导者获取索引副本。

http://_follower_host:port_/solr/_core_name_/replication?command=fetchindex

您可以传递一个额外属性，例如 leaderUrl 或 compression（或 配置跟随者服务器 中描述的任何其他参数），以从领导者进行一次性复制。这消除了在跟随者配置中硬编码领导者 URL 的需要。

abortfetch

中止从领导者复制索引到指定跟随者的操作。

http://_follower_host:port_/solr/_core_name_/replication?command=abortfetch
enablepoll

启用指定的跟随者轮询领导者上的更改。

http://_follower_host:port_/solr/_core_name_/replication?command=enablepoll
disablepoll

禁用指定的跟随者轮询领导者上的更改。

http://_follower_host:port_/solr/_core_name_/replication?command=disablepoll
details

检索配置详细信息和当前状态。

http://_follower_host:port_/solr/_core_name_/replication?command=details
filelist

检索指定主机索引中存在的 Lucene 文件列表。

V1 API

http://_host:port_/solr/_core_name_/replication?command=filelist&generation=<_generation-number_>

V2 API

http://_host:port_/api/cores/_core_name_/replication/files?generation=<_generation-number_>

您可以通过运行 indexversion 命令来发现索引的生成号。

backup

如果服务器中有已提交的索引数据，则在领导者上创建备份；否则，不执行任何操作。

http://_leader_host:port_/solr/_core_name_/replication?command=backup

此命令对于进行定期备份非常有用。有几个受支持的请求参数

numberToKeep

这可与备份命令一起使用，除非已在处理程序上指定了 maxNumberOfBackups 初始化参数，在这种情况下，始终使用 maxNumberOfBackups，并且尝试使用 numberToKeep 请求参数将导致错误。

name

（可选）备份名称。快照将创建在核心数据目录中的名为 snapshot.<name> 的目录中。默认情况下，名称使用 yyyyMMddHHmmssSSS 格式的日期生成。如果传递了 location 参数，则将使用该参数代替数据目录。

repository

要使用的备份存储库的名称。未指定时，默认为本地文件系统。

location

备份位置。该值取决于所使用的存储库。对于文件系统存储库，位置默认为核心的 dataDir（数据目录），如果指定，则需要在 SOLR_HOME、SOLR_DATA_HOME 或 solr.xml allowPaths 参数指定的路径中。

restore

从备份存储库还原备份。

http://_leader_host:port_/solr/_core_name_/replication?command=restore

此命令用于还原备份。支持几个请求参数

name

（可选）备份名称。要还原的备份索引快照的名称。如果未提供名称，它将在位置目录中查找格式为 snapshot.<timestamp> 的备份。在这种情况下，它将选择最新的时间戳备份。

repository

备份存储库的名称，其中包含备份。未指定时，它默认为本地文件系统。

location

备份位置。该值取决于所使用的存储库。对于文件系统存储库，位置默认为核心 dataDir（数据目录），如果指定，则需要在 SOLR_HOME、SOLR_DATA_HOME 或由 solr.xml allowPaths 参数指定的路径中。

restorestatus

检查正在运行的还原操作的状态。

http://_leader_host:port_/solr/_core_name_/replication?command=restorestatus

此命令用于检查还原操作的状态。此命令不采用任何参数。

状态值可以是“正在进行”、“成功”或“失败”。如果失败，则响应中还会发送“异常”。

deletebackup

删除使用 backup 命令创建的任何备份。

http://_leader_host:port_ /solr/_core_name_/replication?command=deletebackup

支持两个参数

name

快照名称。名称为 snapshot.name 的快照必须存在，否则将返回错误。

location

创建快照的位置。

优化分布式索引

优化索引并不是大多数用户通常需要担心的事情 - 但在使用 ReplicationHandler 时，用户应特别注意优化索引的影响。

优化领导者索引所需的时间可能会有很大差异。小型索引可以在几分钟内优化。非常大的索引可能需要几个小时。变量包括索引的大小和硬件的速度。

分发新优化的索引可能只需要几分钟或最多一个小时或更长时间，这又取决于索引的大小以及网络连接和磁盘的性能能力。在优化期间，机器处于负载状态，并且无法很好地处理查询。鉴于每小时对从属项进行更新的计划，我们无法针对每个已提交的快照运行优化。

复制优化后的索引意味着在下一个 snappull 期间需要传输整个索引。这是一笔很大的开销，但远没有在所有地方运行优化那么大。

考虑以下示例：在三从一主配置中，分发新优化的索引大约需要 80 秒总共。在层级中滚动更改每个机器（或机器组）大约需要十分钟。如果在查询层级中滚动此优化，并且每个被优化的从属节点都被禁用且不接收查询，则推出将至少需要二十分钟，甚至可能长达一个半小时。此外，需要同步文件，以便在优化之后，snappull 不会认为独立优化的文件有任何不同。这也为索引的独立损坏敞开了大门，而不是每个索引都是主节点的完美副本。

在主节点上优化允许进行直接的优化操作。无需将任何查询从属节点移出服务。可以在后台分发优化后的索引，同时正常处理查询。优化可以在为索引更新提供服务的应用程序方便的任何时间进行。

虽然优化在某些情况下可能有一些好处，但快速变化的索引不会长期保留这些好处，并且由于优化是一个密集的过程，因此最好考虑其他选项，例如降低合并因子（在控制段大小部分中讨论）。

除非您有确凿的证据表明优化将显著提高您的搜索性能，否则不要选择优化您的索引。