Solr配置：CoreAdmin API完整指南

Posted on 本文总阅读量次

Core Admin API主要在运行SolrCloud集群时由Collections API在底层使用。

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

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

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

所有操作名称都是大写的，并在下面的部分中深入定义。

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

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

我们传递了configSetBaseDir的显式相对路径，以便能够在下面的示例中使用sample_techproducts_configs configset创建新核心。

STATUS

STATUS操作返回所有运行中的Solr核心的状态，或仅返回指定核心的状态。

V1 API

1
http://localhost:8983/solr/admin/cores?action=STATUS&core=techproducts

V2 API

1
2
3
4
5
6
7
8
# 获取所有核心状态
curl -X GET http://localhost:8983/api/cores/

# 获取单个核心状态
curl -X GET http://localhost:8983/api/cores/techproducts

# 跳过返回索引信息
curl -X GET http://localhost:8983/api/cores?indexInfo=false

STATUS参数

core（可选，默认：none）：
核心的名称，如solr.xml中<core>元素的”name”属性中列出的。
如果省略此参数，将返回所有运行核心的状态。

indexInfo（可选，默认：true）：
如果为false，索引信息不会与核心STATUS请求一起返回。
在具有大量核心（即数百个以上）的Solr实现中，检索每个核心的索引信息可能需要很长时间，而且并不总是需要的。

CREATE

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

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

V1 API

假设你使用现有的configSet创建新核心：

1
http://localhost:8983/solr/admin/cores?action=CREATE&name=techproducts_v2&configSet=sample_techproducts_configs

如果你已有部署在磁盘上的现有核心文件，只需从它们创建Solr核心，则URL将类似于：

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

V2 API

1
2
3
4
5
6
7
8
curl -X POST http://localhost:8983/api/cores -H 'Content-Type: application/json' -d '
  {
    "create": {
      "name": "techproducts_v2",
      "configSet": "sample_techproducts_configs"
    }
  }
'

注意此命令是Core Admin API命令中唯一不支持core参数的命令。
相反，需要name参数，如下所示。

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

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

对于用户管理的集群，如果你定义了配置集，可以使用下面记录的configSet参数。
如果没有配置集，则CREATE调用中指定的instanceDir必须已存在，并且必须包含conf目录，该目录又必须包含solrconfig.xml、你的schema（通常命名为managed-schema.xml或schema.xml）以及这些配置引用的任何文件。

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

CREATE和core.properties文件

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

CREATE核心参数

name（必需，默认：none）：
新核心的名称。
与<core>元素上的name相同。

instanceDir（可选，默认：见描述）：
存储此核心文件的目录。
与<core>元素上的instanceDir相同。
如果不提供，默认值是为name参数指定的值。
此目录必须在SOLR_HOME、SOLR_DATA_HOME或系统属性solr.allowPaths指定的路径之一内。

config（可选，默认：solrconfig.xml）：
相对于instanceDir的配置文件名（即solrconfig.xml）。

schema（可选，默认：见描述）：
用于核心的schema文件名。
请注意，如果你使用的是”托管schema”（默认行为），那么此属性的任何值如果不匹配有效的managedSchemaResourceName将被读取一次、备份，并转换为托管schema使用。
有关详细信息，请参见Schema工厂。

dataDir（可选，默认：data）：
相对于instanceDir的数据目录名称。
如果使用绝对值，它必须在SOLR_HOME、SOLR_DATA_HOME或系统属性solr.allowPaths指定的路径之一内。

configSet（可选，默认：none）：
用于此核心的configset名称。
有关更多信息，请参见配置集部分。

collection（可选，默认：见描述）：
此核心所属集合的名称。
默认为核心的名称。
collection._param_=_value_导致如果正在创建新集合，设置属性_param_=_value_。
使用collection.configName=_config-name_指向新集合的配置。

警告：虽然可以为不存在的集合创建核心，但这种方法不受支持且不推荐。
在为其直接创建核心之前，始终使用Collections API创建集合。

shard（可选，默认：none）：
此核心代表的分片ID。
这应该只在特殊情况下需要；通常你希望被自动分配分片ID。

property.name=value（可选，默认：none）：
将核心属性_name_设置为_value_。
请参见定义core.properties文件内容的部分。

async（可选，默认：none）：
请求ID以跟踪此操作，将异步处理。

CREATE示例

1
http://localhost:8983/solr/admin/cores?action=CREATE&name=my_core&collection=my_collection&shard=shard2

RELOAD

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

V1 API

1
http://localhost:8983/solr/admin/cores?action=RELOAD&core=techproducts

V2 API

1
curl -X POST http://localhost:8983/api/cores/techproducts/reload

当你对Solr核心在磁盘上的配置进行了更改时，这很有用，例如添加新字段定义。
调用RELOAD操作让你应用新配置而无需重启Solr。

重要

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

RELOAD核心参数

core（可选，默认：none）：
核心的名称，如solr.xml中<core>元素的”name”属性中列出的。
此参数在v1中是必需的，在v2 API中是URL的一部分。

RENAME

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

V1 API

1
curl -X GET "http://localhost:8983/solr/admin/cores?action=RENAME&core=currentCoreName&other=newCoreName"

V2 API

1
2
3
4
5
curl -X POST http://localhost:8983/api/cores/currentCoreName/rename -H 'Content-Type: application/json' -d '
  {
    "to": "newCoreName"
  }
'

RENAME参数

core（必需，默认：none）：
要重命名的现有Solr核心的名称。
如果发出v1请求，指定为查询参数；如果使用v2 API，指定为路径参数。

other（v1）、to（v2）（必需，默认：none）：
Solr核心的新名称。
如果发出v1请求，指定为查询参数；如果使用v2 API，指定为请求正文中的属性。
如果<solr>的持久属性为true，新名称将作为<core>属性的name属性写入solr.xml。

async（可选，默认：none）：
请求ID以跟踪此操作，将异步处理。

SWAP

SWAP原子交换用于访问两个现有Solr核心的名称。
这可用于将新内容交换到生产环境中。
之前的核心仍可用，如有必要可以交换回来。
交换后，每个核心将以另一个核心的名称知名。

V1 API

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

V2 API

1
2
3
4
5
curl -X POST http://localhost:8983/api/cores/_core-name_/swap -H 'Content-Type: application/json' -d '
  {
    "with": "_other-core-name_"
  }
'

重要

不要对SolrCloud节点使用SWAP。
这不受支持，可能导致核心无法使用。

SWAP参数

core（必需，默认：none）：
要交换的核心之一的名称。

other（必需，默认：none）：
要交换的另一个核心的名称。

async（可选，默认：none）：
请求ID以跟踪此操作，将异步处理。

UNLOAD

UNLOAD操作从Solr中移除核心。
活动请求将继续处理，但不会向指定核心发送新请求。
如果核心注册在多个名称下，只有给定的名称被移除。

V1 API

1
http://localhost:8983/solr/admin/cores?actionUNLOAD&core=techproducts

V2 API

1
2
3
curl -X POST http://localhost:8983/api/cores/techproducts/unload -H 'Content-Type: application/json' -d '
  {}
'

UNLOAD操作需要一个参数（core）识别要移除的核心。
如果<solr>的持久属性设置为true，具有此name属性的<core>元素将从solr.xml中移除。

重要

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

UNLOAD参数

core（必需，默认：none）：
要移除的核心名称。
此参数是必需的。

deleteIndex（可选，默认：false）：
如果为true，卸载核心时将移除索引。

deleteDataDir（可选，默认：false）：
如果为true，移除data目录及所有子目录。

deleteInstanceDir（可选，默认：false）：
如果为true，移除与核心相关的所有内容，包括索引目录、配置文件和其他相关文件。

async（可选，默认：none）：
请求ID以跟踪此操作，将异步处理。

MERGEINDEXES

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

使用indexDir参数

V1 API

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

V2 API

1
2
3
4
5
curl -X POST http://localhost:8983/api/cores/targetCoreName/merge-indices -H 'Content-Type: application/json' -d '
{
  "indexDirs": ["path/to/core1/data/index","path/to/core2/data/index"]
}
'

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

使用srcCore参数

V1 API

1
curl -X GET "http://localhost:8983/solr/admin/cores?action=mergeindexes&core=targetCoreName&srcCore=core1&srcCore=core2"

V2 API

1
2
3
4
5
curl -X POST http://localhost:8983/api/cores/targetCoreName/merge-indices -H 'Content-Type: application/json' -d '
{
  "srcCores": ["core1","core2"]
}
'

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

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

MERGEINDEXES参数

core（必需，默认：none）：
目标核心/索引的名称。

indexDir（可选，默认：none）：
多值，要合并的目录。

srcCore（可选，默认：none）：
多值，要合并的源核心。

async（可选，默认：none）：
请求ID以跟踪此操作，将异步处理。

SPLIT

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

SPLIT参数

core（必需，默认：none）：
要拆分的核心名称。

path（可选，默认：none）：
多值，索引片段将写入的目录路径。
必须指定此参数或targetCore。
如果指定此参数，不能使用targetCore参数。

targetCore（可选，默认：none）：
多值，索引片段将合并到的目标Solr核心。
必须指定此参数或path。
如果指定此参数，不能使用path参数。

ranges（可选，默认：none）：
十六进制格式的哈希范围的逗号分隔列表。
如果使用此参数，不应使用split.key。
请参见下面的SPLIT示例了解如何使用此参数的示例。

split.key（可选，默认：none）：
用于拆分索引的键。
如果使用此参数，不应使用ranges。
请参见下面的SPLIT示例了解如何使用此参数的示例。

async（可选，默认：none）：
请求ID以跟踪此操作，将异步处理。

SPLIT示例

core索引将被拆分成与path或targetCore参数数量相等的片段。

使用两个targetCore参数：

1
http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2

这里core索引将被拆分成两片并合并到两个targetCore索引中。

使用两个path参数：

1
http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&path=/path/to/index/1&path=/path/to/index/2

core索引将被拆分成两片并写入指定的两个目录路径。

使用split.key参数：

1
http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&split.key=A!

这里所有具有与split.key（即A!）相同路由键的文档将从core索引拆分并写入targetCore。

使用ranges参数：

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

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

targetCore必须已存在并且必须具有与core索引兼容的schema。
在拆分之前，会自动在core索引上调用提交。

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

REQUESTSTATUS

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

V1 API

1
http://localhost:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=id

V2 API

1
curl -X GET http://localhost:8983/api/node/commands/id

Core REQUESTSTATUS参数

REQUESTSTATUS命令只有一个参数。

requestid（必需，默认：none）：
异步请求的用户定义请求ID。

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

1
http://localhost:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=1

REQUESTRECOVERY

REQUESTRECOVERY操作通过与leader同步手动要求核心恢复。
这应该被视为”专家”级别命令，应在节点（SolrCloud副本）无法自动变为活动状态的情况下使用。

1
admin/cores?action=REQUESTRECOVERY&core=_core-name_

REQUESTRECOVERY参数

core（必需，默认：none）：
要重新同步的核心名称。

REQUESTRECOVERY示例

1
http://localhost:8981/solr/admin/cores?action=REQUESTRECOVERY&core=gettingstarted_shard1_replica1

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

Solr配置 Solr配置 CoreAdmin API 核心管理 API操作 核心维护
© 2025 Solr Community of China All Rights Reserved. 本站访客数人次 本站总访问量次
Theme by hiero