CoreAdmin API

核心管理 API 主要在运行 SolrCloud 集群时由 Collections API 在底层使用。

SolrCloud 用户通常不应直接使用 CoreAdmin API,但对于用户管理的集群或用于核心维护操作的单节点安装,该 API 可能很有用。

CoreAdmin API 由 CoreAdminHandler 实现,CoreAdminHandler 是一个特殊用途的请求处理器,用于管理 Solr 核心。与其他请求处理器不同,CoreAdminHandler 不附加到单个核心。相反,每个 Solr 节点中都有一个 CoreAdminHandler 实例,用于管理该节点中运行的所有核心,并且可以通过 /solr/admin/cores 路径访问。

可以通过 HTTP 请求执行 CoreAdmin 操作,该请求指定一个 action 请求参数,并将其他操作特定的参数作为附加参数提供。

所有操作名称均为大写,并在以下部分中进行深入定义。

本节中的所有示例都假设您正在运行“techproducts”Solr 示例

bin/solr start -DconfigSetBaseDir=./server/solr/configsets -e techproducts
bash

我们正在传递 configSetBaseDir 的显式相对路径,以支持在以下示例中使用 sample_techproducts_configs 配置集创建新核心。

状态

STATUS 操作返回所有正在运行的 Solr 核心的状态,或仅返回指定名称的核心的状态。

https://127.0.0.1:8983/solr/admin/cores?action=STATUS&core=techproducts
bash

状态参数

core

可选

默认:无

核心的名称,如 solr.xml<core> 元素的 "name" 属性中所列。如果省略此参数,则会返回所有正在运行的核心的状态。

indexInfo

可选

默认值:true

如果为 false,则有关索引的信息将不会与核心 STATUS 请求一起返回。在具有大量核心(即,超过数百个)的 Solr 实现中,检索每个核心的索引信息可能需要很长时间,而且并非总是必需的。

创建

CREATE 操作会创建一个新核心并注册它。

如果已存在具有给定名称的 Solr 核心,则在初始化新核心时,它将继续处理请求。当新核心准备就绪时,它将接收新的请求,而旧核心将被卸载。

admin/cores?action=CREATE&name=core-name&instanceDir=path/to/dir&config=solrconfig.xml&dataDir=data

假设您正在使用现有的配置集来创建新核心

https://127.0.0.1:8983/solr/admin/cores?action=CREATE&&name=techproducts_v2&configSet=sample_techproducts_configs
bash

如果磁盘上已经部署了现有的核心文件,并且只需要从它们创建 Solr 核心,则 url 将如下所示

https://127.0.0.1:8983/solr/admin/cores?action=CREATE&name=_core-name_&instanceDir=_path/to/dir_&config=solrconfig.xml&dataDir=data
bash

请注意,此命令是 Core Admin API 命令中唯一一个不支持 core 参数的命令。相反,必须使用 name 参数,如下所示。

请注意,CREATE 必须能够找到配置,否则将不会成功。

当您运行 SolrCloud 并为集合创建新核心时,配置将从该集合继承。每个集合都链接到存储在 ZooKeeper 中的 configName。这满足了配置要求。也就是说,如果您正在运行 SolrCloud,则不应使用 CoreAdmin API。相反,请使用 Collections API

对于用户管理的集群,如果定义了配置集 (Configsets),则可以使用如下所述的 configSet 参数。如果没有配置集,那么 CREATE 调用中指定的 instanceDir 必须已存在,并且必须包含一个 conf 目录,该目录又必须包含 solrconfig.xml、您的模式(通常命名为 managed-schema.xmlschema.xml)以及这些配置引用的任何文件。

可以使用 configschema 参数指定配置和模式文件名,但这些是专家选项。您可以执行的一件事来避免创建 conf 目录是使用指向绝对路径的 configschema 参数,但这可能会导致令人困惑的配置,除非您完全了解自己在做什么。

CREATE 和 core.properties 文件

core.properties 文件是作为 CREATE 命令的一部分构建的。如果您自己在核心目录中创建了一个 core.properties 文件,然后尝试使用 CREATE 将该核心添加到 Solr,则会收到一个错误,告诉您另一个核心已经定义在那里。在调用带有 CREATE 命令的 CoreAdmin API 之前,core.properties 文件不得存在。

CREATE 核心参数

name

必需

默认:无

新核心的名称。与 <core> 元素上的 name 相同。

instanceDir

可选

默认值:请参见描述

应存储此核心文件的目录。与 <core> 元素上的 instanceDir 相同。如果未提供,则默认值为为 name 参数指定的值。此目录必须位于 SOLR_HOMESOLR_DATA_HOME 或系统属性 solr.allowPaths 指定的路径之一内。

config

可选

默认值:solrconfig.xml

相对于 instanceDir 的配置文件名称(即 solrconfig.xml)。

schema

可选

默认值:请参见描述

用于核心的模式文件的名称。请注意,如果您使用的是“托管模式”(默认行为),那么此属性的任何与实际的 managedSchemaResourceName 不匹配的值都将被读取一次、备份并转换为托管模式使用。有关详细信息,请参阅模式工厂配置

dataDir

可选

默认值:data

相对于 instanceDir 的数据目录名称。如果使用绝对值,则它必须位于 SOLR_HOMESOLR_DATA_HOME 或系统属性 solr.allowPaths 指定的路径之一内。

configSet

可选

默认:无

要用于此核心的配置集的名称。有关更多信息,请参阅配置集部分。

collection

可选

默认值:请参见描述

此核心所属的集合的名称。默认值是核心的名称。如果正在创建新集合,则 collection.param=value 将设置属性 param=value。使用 collection.configName=config-name 指向新集合的配置。

尽管可以为不存在的集合创建核心,但不建议使用这种方法,也不支持。始终在使用 Collections API 直接为其创建核心之前创建集合。
shard

可选

默认:无

此核心表示的分片 ID。这仅在特殊情况下才是必需的;通常,您希望自动分配分片 ID。

property.name=value

可选

默认:无

将核心属性 name 设置为 value。请参阅关于定义 core.properties 文件内容的部分。

async

可选

默认:无

用于跟踪此异步处理操作的请求 ID。

使用 collection.configName=configname 指向新集合的配置。

CREATE 示例

https://127.0.0.1:8983/solr/admin/cores?action=CREATE&name=my_core&collection=my_collection&shard=shard2
bash

RELOAD

RELOAD 操作从现有已注册的 Solr 核心的配置中加载新的核心。在新核心初始化时,现有核心将继续处理请求。当新的 Solr 核心准备就绪时,它将接管并且卸载旧的核心。

https://127.0.0.1:8983/solr/admin/cores?action=RELOAD&core=techproducts
bash

当您对磁盘上的 Solr 核心配置进行了更改(例如添加新的字段定义)时,此功能非常有用。调用 RELOAD 操作使您可以应用新的配置,而无需重新启动 Solr。

RELOAD 执行 SolrCore 的“实时”重新加载,重用一些现有对象。一些配置选项(例如 dataDir 位置和 solrconfig.xml 中的 IndexWriter 相关设置)不能通过简单的 RELOAD 操作进行更改和激活。

RELOAD 核心参数

core

可选

默认:无

核心的名称,如 solr.xml<core> 元素的“name”属性中所列。此参数在 v1 中是必需的,并且是 v2 API 中 URL 的一部分。

RENAME

RENAME 操作会更改 Solr 核心的名称。

curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=RENAME&core=currentCoreName&other=newCoreName"
bash

RENAME 参数

core

必需

默认:无

要重命名的现有 Solr 核心的名称。如果在发出 v1 请求时作为查询参数指定,或者如果使用 v2 API 时作为路径参数指定。

other (v1), to (v2)

必需

默认:无

Solr 核心的新名称。如果在发出 v1 请求时作为查询参数指定,或者如果使用 v2 API 时作为请求正文中的属性指定。如果 <solr> 的持久属性为 true,则新名称将作为 <core> 属性的 name 属性写入 solr.xml

async

可选

默认:无

用于跟踪此异步处理操作的请求 ID。

SWAP

SWAP 原子性地交换用于访问两个现有 Solr 核心的名称。这可以用于将新内容交换到生产环境中。如有必要,先前的核心仍然可用并且可以交换回来。交换后,每个核心都将以另一个核心的名称而为人所知。

`admin/cores?action=SWAP&core=_core-name_&other=_other-core-name_`
bash

请勿在 SolrCloud 节点上使用 SWAP。不支持它,并且可能会导致核心无法使用。

SWAP 参数

core

必需

默认:无

要交换的核心之一的名称。

other

必需

默认:无

要交换的另一个核心的名称。

async

可选

默认:无

用于跟踪此异步处理操作的请求 ID。

UNLOAD

UNLOAD 操作从 Solr 中删除核心。活动请求将继续处理,但不会向指定的核心发送新请求。如果一个核心注册了多个名称,则仅删除给定的名称。

https://127.0.0.1:8983/solr/admin/cores?actionUNLOAD&core=techproducts
bash

UNLOAD 操作需要一个参数 (core) 来标识要删除的核心。如果 <solr> 的持久属性设置为 true,则将从 solr.xml 中删除具有此 name 属性的 <core> 元素。

卸载 SolrCloud 集合中的所有核心会导致从 ZooKeeper 中删除该集合的元数据。

UNLOAD 参数

core

必需

默认:无

要删除的核心的名称。此参数是必需的。

deleteIndex

可选

默认值:false

如果为 true,则在卸载核心时删除索引。

deleteDataDir

可选

默认值:false

如果为 true,则删除 data 目录和所有子目录。

deleteInstanceDir

可选

默认值:false

如果为 true,则删除与核心相关的所有内容,包括索引目录、配置文件和其他相关文件。

async

可选

默认:无

用于跟踪此异步处理操作的请求 ID。

MERGEINDEXES

MERGEINDEXES 操作将一个或多个索引合并到另一个索引。这些索引必须已完成提交,并且应锁定以防止写入,直到合并完成,否则生成的合并索引可能会损坏。目标核心索引必须已经存在,并且与将合并到其中的一个或多个索引具有兼容的模式。合并完成后,还应在目标核心上执行另一次提交。

curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=MERGEINDEXES&core=targetCoreName&indexDir=path/to/core1/data/index&indexDir=path/to/core2/data/index"
bash

在此示例中,我们使用 indexDir 参数(v2 API 中的 indexDirs)定义源核心的索引位置。core 参数定义目标索引。这种方法的一个好处是,我们可以合并任何可能未与 Solr 核心关联的基于 Lucene 的索引。

或者,我们可以改为使用 srcCore 参数(v2 API 中的 srcCores),如下面的示例所示

curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=mergeindexes&core=targetCoreName&srcCore=core1&srcCore=core2"
bash

这种方法允许我们定义可能没有与目标核心位于同一物理服务器上的索引路径的核心。但是,我们只能将 Solr 核心用作源索引。这种方法的另一个好处是,如果写入与源索引并行发生,我们损坏的风险不会那么高。

我们可以通过指定 async 参数并传递请求 ID 来使此调用异步运行。然后,可以使用此 ID 使用 REQUESTSTATUS API 检查已提交任务的状态。

MERGEINDEXES 参数

core

必需

默认:无

目标核心/索引的名称。

indexDir

可选

默认:无

多值,要合并的目录。

srcCore

可选

默认:无

多值,要合并的源核心。

async

可选

默认:无

用于跟踪此异步处理操作的请求 ID。

SPLIT

SPLIT 操作将索引拆分为两个或多个索引。正在拆分的索引可以继续处理请求。拆分的部分可以放置在服务器文件系统上的指定目录中,也可以合并到正在运行的 Solr 核心中。

SPLIT 操作支持五个参数,这些参数在下表中进行描述。

SPLIT 参数

core

必需

默认:无

要拆分的核心的名称。

path

可选

默认:无

多值,将在其中写入索引一部分的目录路径。必须指定此参数或 targetCore。如果指定了此参数,则不能使用 targetCore 参数。

targetCore

可选

默认:无

多值,索引的一部分将合并到的目标 Solr 核心。必须指定此参数或 path。如果指定了此参数,则不能使用 path 参数。

ranges

可选

默认:无

以十六进制格式表示的哈希范围的逗号分隔列表。如果使用此参数,则不应使用 split.key。有关如何使用此参数的示例,请参见下面的SPLIT 示例

split.key

可选

默认:无

用于拆分索引的键。如果使用此参数,则不应使用 ranges。有关如何使用此参数的示例,请参见下面的SPLIT 示例

async

可选

默认:无

用于跟踪此异步处理操作的请求 ID。

SPLIT 示例

core 索引将拆分为与 pathtargetCore 参数的数量一样多的部分。

与两个 targetCore 参数一起使用:

https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2
bash

此处,core 索引将拆分为两部分并合并到两个 targetCore 索引中。

与两个 path 参数一起使用:

https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&path=/path/to/index/1&path=/path/to/index/2
bash

core 索引将拆分为两部分并写入指定的两个目录路径中。

与 split.key 参数一起使用:

https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&split.key=A!
bash

此处,所有具有与 split.key(即 A!)相同的路由键的文档将从 core 索引中拆分并写入到 targetCore

与 ranges 参数一起使用:

https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2&targetCore=core3&ranges=0-1f4,1f5-3e8,3e9-5dc
bash

此示例使用 ranges 参数,并以十六进制指定哈希范围 0-500、501-1000 和 1001-1500。此处,索引将拆分为三个部分,每个 targetCore 接收与指定的哈希范围匹配的文档,即 core1 将获得哈希范围为 0-500 的文档,core2 将接收哈希范围为 501-1000 的文档,最后,core3 将接收哈希范围为 1001-1500 的文档。必须至少指定一个哈希范围。请注意,使用等于路由键的哈希范围的单个哈希范围与使用 split.key 参数不等效,因为多个路由键可以哈希到同一范围。

targetCore 必须已经存在,并且必须与 core 索引具有兼容的模式。在拆分之前,将自动在 core 索引上调用提交。

此命令用作 SolrCloud 的 SPLITSHARD 命令的一部分,但它也可以用于用户管理的集群中的核心。当对用户管理集群中的核心使用,且没有 split.key 参数时,此操作将拆分源索引并交替分发其文档,以便每个拆分片段包含相同数量的文档。如果指定了 split.key 参数,则只有具有相同路由键的文档会从源索引中拆分。

REQUESTSTATUS

请求已提交的异步 CoreAdmin API 调用的状态。

https://127.0.0.1:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=id
bash

Core REQUESTSTATUS 参数

REQUESTSTATUS 命令只有一个参数。

requestid

必需

默认:无

异步请求的用户定义的请求 ID。

以下调用将返回已提交的异步 CoreAdmin 调用的状态。

https://127.0.0.1:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=1
bash

REQUESTRECOVERY

REQUESTRECOVERY 操作手动请求核心通过与领导者同步来恢复。这应该被认为是“专家”级命令,应该在节点(SolrCloud 副本)无法自动变为活动状态的情况下使用。

admin/cores?action=REQUESTRECOVERY&core=核心名称

REQUESTRECOVERY 参数

core

必需

默认:无

要重新同步的核心的名称。

REQUESTRECOVERY 示例

https://127.0.0.1:8981/solr/admin/cores?action=REQUESTRECOVERY&core=gettingstarted_shard1_replica1
bash

可以通过 admin UI 展开相应的 ZooKeeper 节点来找到要指定的核心。