用户管理的索引复制

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

下图显示了使用索引复制的 Solr 配置。主服务器的索引会复制到从属服务器上。

图 1. Solr 索引可以跨多个从属服务器复制，然后这些服务器处理请求。

Solr 中的索引复制

Solr 包括通过 HTTP 进行索引复制的功能

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

SolrCloud 中的复制

尽管在 SolrCloud 集群中没有主节点或从属节点的明确概念，但此页面讨论的 ReplicationHandler 仍然由 SolrCloud 根据需要用于支持“分片恢复”，但这以对等方式完成。

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

配置 ReplicationHandler

除了下面描述的特定于主角色和从属角色的 ReplicationHandler 配置选项之外，还有一些通常支持的特殊配置选项（即使在使用 SolrCloud 时）。

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

配置 Leader 服务器

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

replicateAfter

可选

默认值：无

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

commit：每当在 leader 索引上执行提交时触发复制。
optimize：每当 leader 索引被优化时触发复制。
startup：每当 leader 索引启动时触发复制。

此参数可以有多个值，如

<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

可选

默认值：无

要复制到 follower 的配置文件，用逗号分隔。这些应该是模式、停用词和类似的配置文件，这些文件可能会在 leader 上更改，并且需要在 follower 上更新以便在服务查询时使用。

如果要复制 solrconfig.xml，则需要特别注意，以免 leader 的配置覆盖 follower 的配置。如下所示的行将确保本地配置 solrconfig_follower.xml 将在 follower 上保存为 solrconfig.xml

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

在 leader 服务器上，follower 配置文件的文件名可以是任何名称，只要该名称在 confFiles 字符串中被正确标识即可；然后它将保存为冒号 ':' 之后出现的任何文件名。在上面的示例中，所有其他文件将以其原始名称保存。

commitReserveDuration

可选	默认值：`00:00:10`

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

下面的示例显示了 ReplicationHandler 的可能的“leader”配置，包括固定数量的备份和一个 maxWriteMBPerSec 请求参数的不变设置，以防止 follower 使其网络接口饱和

<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>

配置 Follower 服务器

follower 配置需要与 leader 不同，因为在这种方法中，follower 会向 leader 发起请求以获取更新的索引和其他文件。

我们使用以下参数

leaderUrl

可选

默认值：无

leader 的复制处理程序的完全限定 URL。

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

pollInterval

可选

默认值：无

follower 应轮询 leader 的间隔。格式为 HH:mm:ss。如果缺少此项，则 follower 不会自动轮询。

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

compression

可选

默认值：无

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

虽然此参数对于一般用途似乎是一个好主意，但通常只有在 leader 和 follower 节点之间的带宽持续较低时才需要它。

httpConnTimeout

可选	默认值：`5000`

等待与 leader 建立连接的时间长度（以毫秒为单位）。除非带宽极低或延迟极高，否则通常可以将其保留为默认值。

httpReadTimeout

可选	默认值：`10000`

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

httpBasicAuthUser

可选

默认值：无

如果 leader 配置了 HTTP 基本身份验证，则要使用的用户名。

httpBasicAuthPassword

可选

默认值：无

如果 leader 配置了 HTTP 基本身份验证，则要使用的密码。

以下示例显示了 follower 上的 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 设置中继器

一个 leader 可能只能为一定数量的 follower 提供服务，而不会影响性能。一些组织已经在多个数据中心部署了 follower 服务器。如果每个 follower 从远程数据中心下载索引，则导致的下载可能会消耗过多的网络带宽。为了避免这种情况下的性能下降，您可以将一个或多个 follower 配置为中继器。中继器只是一个既充当 leader 又充当 follower 的节点。

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

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

（可选）可以配置中继器以通过 compression 参数从 leader 获取压缩文件，以减少索引下载时间。

以下是中继器的 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，则此屏幕才会出现。

如果您正在使用 Leader-Follower 索引复制，则可以使用此屏幕执行以下操作

查看可复制的索引状态（在 leader 节点上）
查看当前复制状态（在 follower 节点上）
禁用复制（在 leader 节点上）

Follower 复制

leader 完全不知道 follower 的存在。

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

步骤如下

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

复制配置文件

要复制配置文件，请使用 confFiles 参数定义它们。仅复制在 leader 的 Solr 实例的 conf 目录中找到的文件。

Solr 仅在复制索引本身时才会复制配置文件。这意味着，即使 leader 上的配置文件发生更改，该文件也只有在 leader 的索引上进行新的提交或优化后才会被复制。

与时间戳足以确定索引文件是否相同不同，配置文件会与其校验和进行比较。如果校验和相同，则将模式文件（在 leader 和 follower 上）判断为相同。

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

如果复制至少涉及下载一个配置文件，则 ReplicationHandler 会发出 core-reload 命令而不是提交命令。

解决 Follower 服务器上的损坏问题

如果将文档添加到 follower，则 follower 将不再与其 leader 同步。但是，在 leader 拥有新的索引数据之前，follower 不会采取任何操作使其自身同步。

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

为了纠正此问题，follower 会将所有索引文件从 leader 复制到新的索引目录，并要求内核从新目录加载新索引。

ReplicationHandler 的 HTTP API 命令

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

enablereplication

为所有 follower 启用“leader”上的复制。

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

disablereplication

禁用 leader 上所有 follower 的复制。

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

indexversion

返回指定 leader 或 follower 上最新可复制索引的版本。

V1 API

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

V2 API

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

fetchindex

强制指定的 follower 从其 leader 获取索引副本。

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

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

abortfetch

中止将索引从 leader 复制到指定的 follower。

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: （可选）备份名称。要还原的备份索引快照的名称。如果未提供名称，它将在 location 目录中查找具有 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 秒。在整个层中推出更改需要每台机器（或机器组）大约 10 分钟。如果此优化在查询层中推出，并且禁用每个正在优化的跟随者节点并且不接收查询，则推出至少需要 20 分钟，并且可能长达一个半小时。此外，还需要同步文件，以便在优化**之后**，snappull 不会认为独立优化的文件有任何不同。这也为索引的独立损坏打开了大门，而不是每个都是领导者的完美副本。

在领导者上进行优化可以进行直接的优化操作。不需要将任何查询跟随者停止服务。优化的索引可以在后台分发，同时正常处理查询。优化可以在提供索引更新的应用程序方便的任何时间进行。

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

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