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 核心的状态,或仅返回指定名称的核心的状态。
-
V1 API
-
V2 API
https://127.0.0.1:8983/solr/admin/cores?action=STATUS&core=techproducts
bash
curl -X GET https://127.0.0.1:8983/api/cores/
bash
要获取单个核心的状态
curl -X GET https://127.0.0.1:8983/api/cores/techproducts
bash
要跳过返回有关索引的信息
curl -X GET https://127.0.0.1:8983/api/cores?indexInfo=false
bash
创建
CREATE
操作会创建一个新核心并注册它。
如果已存在具有给定名称的 Solr 核心,则在初始化新核心时,它将继续处理请求。当新核心准备就绪时,它将接收新的请求,而旧核心将被卸载。
admin/cores?action=CREATE&name=core-name&instanceDir=path/to/dir&config=solrconfig.xml&dataDir=data
-
V1 API
-
V2 API
假设您正在使用现有的配置集来创建新核心
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
curl -X POST https://127.0.0.1:8983/api/cores -H 'Content-Type: application/json' -d '
{
"create": {
"name": "techproducts_v2",
"configSet": "sample_techproducts_configs"
}
}
'
bash
请注意,此命令是 Core Admin API 命令中唯一一个不支持 core
参数的命令。相反,必须使用 name
参数,如下所示。
请注意,CREATE 必须能够找到配置,否则将不会成功。
当您运行 SolrCloud 并为集合创建新核心时,配置将从该集合继承。每个集合都链接到存储在 ZooKeeper 中的 configName
。这满足了配置要求。也就是说,如果您正在运行 SolrCloud,则不应使用 CoreAdmin API。相反,请使用 Collections API。
对于用户管理的集群,如果定义了配置集 (Configsets),则可以使用如下所述的 configSet
参数。如果没有配置集,那么 CREATE 调用中指定的 instanceDir
必须已存在,并且必须包含一个 conf
目录,该目录又必须包含 solrconfig.xml
、您的模式(通常命名为 managed-schema.xml
或 schema.xml
)以及这些配置引用的任何文件。
可以使用 config
和 schema
参数指定配置和模式文件名,但这些是专家选项。您可以执行的一件事来避免创建 conf
目录是使用指向绝对路径的 config
和 schema
参数,但这可能会导致令人困惑的配置,除非您完全了解自己在做什么。
CREATE 和
core.properties 文件
|
CREATE 核心参数
name
-
必需
默认:无
新核心的名称。与
<core>
元素上的name
相同。 instanceDir
-
可选
默认值:请参见描述
应存储此核心文件的目录。与
<core>
元素上的instanceDir
相同。如果未提供,则默认值为为name
参数指定的值。此目录必须位于SOLR_HOME
、SOLR_DATA_HOME
或系统属性solr.allowPaths
指定的路径之一内。 config
-
可选
默认值:
solrconfig.xml
相对于
instanceDir
的配置文件名称(即solrconfig.xml
)。 schema
-
可选
默认值:请参见描述
用于核心的模式文件的名称。请注意,如果您使用的是“托管模式”(默认行为),那么此属性的任何与实际的
managedSchemaResourceName
不匹配的值都将被读取一次、备份并转换为托管模式使用。有关详细信息,请参阅模式工厂配置。 dataDir
-
可选
默认值:
data
相对于
instanceDir
的数据目录名称。如果使用绝对值,则它必须位于SOLR_HOME
、SOLR_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
指向新集合的配置。
RELOAD
RELOAD 操作从现有已注册的 Solr 核心的配置中加载新的核心。在新核心初始化时,现有核心将继续处理请求。当新的 Solr 核心准备就绪时,它将接管并且卸载旧的核心。
-
V1 API
-
V2 API
https://127.0.0.1:8983/solr/admin/cores?action=RELOAD&core=techproducts
bash
curl -X POST https://127.0.0.1:8983/api/cores/techproducts/reload
bash
当您对磁盘上的 Solr 核心配置进行了更改(例如添加新的字段定义)时,此功能非常有用。调用 RELOAD 操作使您可以应用新的配置,而无需重新启动 Solr。
RELOAD 执行 SolrCore 的“实时”重新加载,重用一些现有对象。一些配置选项(例如 |
RENAME
RENAME
操作会更改 Solr 核心的名称。
-
V1 API
-
V2 API
curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=RENAME&core=currentCoreName&other=newCoreName"
bash
curl -X POST https://127.0.0.1:8983/api/cores/currentCoreName/rename -H 'Content-Type: application/json' -d '
{
"to": "newCoreName"
}
'
bash
SWAP
SWAP
原子性地交换用于访问两个现有 Solr 核心的名称。这可以用于将新内容交换到生产环境中。如有必要,先前的核心仍然可用并且可以交换回来。交换后,每个核心都将以另一个核心的名称而为人所知。
-
V1 API
-
V2 API
`admin/cores?action=SWAP&core=_core-name_&other=_other-core-name_`
bash
curl -X POST https://127.0.0.1:8983/api/cores/_core-name_/swap -H 'Content-Type: application/json' -d '
{
"with": "_other-core-name_"
}
'
bash
请勿在 SolrCloud 节点上使用 |
UNLOAD
UNLOAD
操作从 Solr 中删除核心。活动请求将继续处理,但不会向指定的核心发送新请求。如果一个核心注册了多个名称,则仅删除给定的名称。
-
V1 API
-
V2 API
https://127.0.0.1:8983/solr/admin/cores?actionUNLOAD&core=techproducts
bash
curl -X POST https://127.0.0.1:8983/api/cores/techproducts/unload -H 'Content-Type: application/json' -d '
{}
'
bash
UNLOAD
操作需要一个参数 (core
) 来标识要删除的核心。如果 <solr>
的持久属性设置为 true
,则将从 solr.xml
中删除具有此 name
属性的 <core>
元素。
卸载 SolrCloud 集合中的所有核心会导致从 ZooKeeper 中删除该集合的元数据。 |
MERGEINDEXES
MERGEINDEXES
操作将一个或多个索引合并到另一个索引。这些索引必须已完成提交,并且应锁定以防止写入,直到合并完成,否则生成的合并索引可能会损坏。目标核心索引必须已经存在,并且与将合并到其中的一个或多个索引具有兼容的模式。合并完成后,还应在目标核心上执行另一次提交。
-
V1 API
-
V2 API
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
curl -X POST https://127.0.0.1:8983/api/cores/targetCoreName/merge-indices -H 'Content-Type: application/json' -d '
{
"indexDirs": ["path/to/core1/data/index","path/to/core2/data/index"]
}
'
bash
在此示例中,我们使用 indexDir
参数(v2 API 中的 indexDirs
)定义源核心的索引位置。core
参数定义目标索引。这种方法的一个好处是,我们可以合并任何可能未与 Solr 核心关联的基于 Lucene 的索引。
或者,我们可以改为使用 srcCore
参数(v2 API 中的 srcCores
),如下面的示例所示
-
V1 API
-
V2 API
curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=mergeindexes&core=targetCoreName&srcCore=core1&srcCore=core2"
bash
curl -X POST https://127.0.0.1:8983/api/cores/targetCoreName/merge-indices -H 'Content-Type: application/json' -d '
{
"srcCores": ["core1","core2"]
}
'
bash
这种方法允许我们定义可能没有与目标核心位于同一物理服务器上的索引路径的核心。但是,我们只能将 Solr 核心用作源索引。这种方法的另一个好处是,如果写入与源索引并行发生,我们损坏的风险不会那么高。
我们可以通过指定 async
参数并传递请求 ID 来使此调用异步运行。然后,可以使用此 ID 使用 REQUESTSTATUS API 检查已提交任务的状态。
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
索引将拆分为与 path
或 targetCore
参数的数量一样多的部分。
与两个 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 调用的状态。
-
V1 API
-
V2 API
https://127.0.0.1:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=id
bash
curl -X GET https://127.0.0.1:8983/api/node/commands/id
bash