CoreAdmin API

2018-12-14 14:47 更新

您在運(yùn)行SolrCloud集群時(shí),核心Admin API主要在Collections API的封面下使用。

SolrCloud用戶通常不應(yīng)該直接使用CoreAdmin API,但是 API 對(duì)于節(jié)點(diǎn)或主從 Solr 安裝的核心維護(hù)操作的用戶可能有用。

CoreAdmin API由CoreAdminHandler實(shí)現(xiàn),CoreAdminHandler是一個(gè)用于管理Solr核心的特殊用途請(qǐng)求處理程序。與其他請(qǐng)求處理程序不同,CoreAdminHandler未附加到單個(gè)核心。相反,在每個(gè)Solr節(jié)點(diǎn)中都有一個(gè)CoreAdminHandler實(shí)例,用于管理在該節(jié)點(diǎn)中運(yùn)行的所有核心,并且可以通過該/solr/admin/cores路徑進(jìn)行訪問。

CoreAdmin操作可以通過HTTP請(qǐng)求來執(zhí)行,這些請(qǐng)求指定一個(gè)action請(qǐng)求參數(shù),其他特定于操作的參數(shù)作為附加參數(shù)提供。

所有的操作名稱都是大寫的,并在下面的部分中進(jìn)行了深入的定義。

STATUS操作

該STATUS操作將返回所有正在運(yùn)行的Solr內(nèi)核的狀態(tài),或僅返回指定內(nèi)核的狀態(tài):

admin/cores?action=STATUS&core=core-name

STATUS參數(shù)

  • core

    核心的名稱,如solr.xml<core>元素的“name”屬性中所列。

  • indexInfo

    如果false,則有關(guān)索引的信息將不會(huì)返回一個(gè)核心狀態(tài)請(qǐng)求。在具有大量?jī)?nèi)核(即,超過數(shù)百個(gè))的Solr實(shí)現(xiàn)中,檢索每個(gè)內(nèi)核的索引信息可能花費(fèi)大量時(shí)間,并且并不總是需要的。默認(rèn)是true。

CREATE操作

CREATE操作將創(chuàng)建一個(gè)新的核心并進(jìn)行注冊(cè)。

如果具有給定名稱的Solr核心已經(jīng)存在,則在新核心初始化時(shí)它將繼續(xù)處理請(qǐng)求。當(dāng)新的核心準(zhǔn)備就緒時(shí),將會(huì)有新的請(qǐng)求,舊核心將被卸載:

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

請(qǐng)注意,此命令是唯一不支持該core參數(shù)的Core Admin API命令。相反,該name參數(shù)是必需的,如下文所示。

注意事項(xiàng):CREATE必須能夠找到一個(gè)配置!CREATE調(diào)用必須能夠找到配置,否則它將無法成功。當(dāng)您在運(yùn)行 SolrCloud 并為集合創(chuàng)建新內(nèi)核時(shí),將從集合繼承配置。每個(gè)集合鏈接到一個(gè)存儲(chǔ)在ZooKeeper中的configName。這滿足配置要求。不過,有一點(diǎn)值得注意--如果您正在運(yùn)行 SolrCloud,則根本不應(yīng)該使用 CoreAdmin API。使用集合 API。
當(dāng)您沒有運(yùn)行 SolrCloud 時(shí),如果定義了配置集,則可以使用 configSet 參數(shù),如下所述。如果沒有配置集,則在 CREATE 調(diào)用中指定的 instanceDir 必須已經(jīng)存在,并且它必須包含一個(gè)conf目錄,該目錄又必須包含solrconfig.xml,您的模式(通常命名為managed-schema或schema.xml)和任何由這些配置引用的文件。
配置和架構(gòu)文件名可以用config和schema參數(shù)指定, 但這些都是專家選項(xiàng)。要避免創(chuàng)建配置目錄,您可以做的一件事是使用指向絕對(duì)路徑的config和schema參數(shù),但是除非你完全理解你在做什么,否則會(huì)導(dǎo)致配置混亂。
Note:CREATE 和core.properties文件:
core.properties文件是作為CREATE命令的一部分生成的。如果您自己在核心目錄中創(chuàng)建了一個(gè)core.properties文件,然后嘗試使用CREATE添加到 Solr 的核心,您會(huì)得到一個(gè)錯(cuò)誤告訴你,另一個(gè)核心已經(jīng)定義在那里。在使用 CREATE 命令調(diào)用 CoreAdmin API 之前,不能存在核心屬性文件。

CREATE Core 參數(shù)

name

新核心的名稱。同<core>元素上的name。該參數(shù)是必需的。

instanceDir

該內(nèi)核的文件應(yīng)該存儲(chǔ)的目錄。同instanceDir在上<core>元素。缺省值是為name參數(shù)指定的值(如果未提供)。

config

配置文件的名稱(例如,solrconfig.xml)相對(duì)于instanceDir。

schema

用于核心的架構(gòu)文件的名稱。請(qǐng)注意,如果您使用的是“托管架構(gòu)”(默認(rèn)行為),那么此屬性的任何值與有效值都不匹配,managedSchemaResourceName將被讀取一次,備份并轉(zhuǎn)換為托管架構(gòu)使用。有關(guān)詳細(xì)信息,請(qǐng)參閱SolrConfig中的架構(gòu)工廠定義。

dataDir

數(shù)據(jù)目錄的名稱,相對(duì)于instanceDir。

configSet

用于此內(nèi)核的configset的名稱。有關(guān)更多信息,請(qǐng)參閱配置集。

collection

此核心所屬的集合的名稱。默認(rèn)是核心的名稱。collection.param=value導(dǎo)致在創(chuàng)建新集合時(shí)要設(shè)置的param=value的屬性。使用collection.configName=config-name指向新集合的配置。

雖然可以為不存在的集合創(chuàng)建核心,但不支持此方法,也不推薦。直接為其創(chuàng)建核心之前,始終使用Collections API創(chuàng)建一個(gè)集合。
shard

這個(gè)核心代表的分片ID。通常您想自動(dòng)分配一個(gè)分片ID。

property.name=value

將核心屬性name設(shè)置為value。請(qǐng)參閱定義core.properties文件內(nèi)容的部分。

async

請(qǐng)求ID來跟蹤這個(gè)將被異步處理的動(dòng)作。

使用collection.configName=configname指向配置為一個(gè)新的集合。

CREATE示例

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

RELOAD操作

RELOAD操作從現(xiàn)有已注冊(cè)的Solr內(nèi)核的配置中加載一個(gè)新的內(nèi)核。在新的核心正在初始化時(shí),現(xiàn)有核心將繼續(xù)處理請(qǐng)求。當(dāng)新的Solr內(nèi)核準(zhǔn)備好時(shí),它接管并卸載舊的內(nèi)核。

admin/cores?action=RELOAD&core=core-name

當(dāng)您對(duì)磁盤上的Solr內(nèi)核配置進(jìn)行更改(如添加新的字段定義)時(shí),這非常有用。調(diào)用RELOAD操作可以應(yīng)用新的配置,而無需重新啟動(dòng)Solr。

RELOAD操作執(zhí)行 SolrCore 的 "實(shí)時(shí)" 重裝,重新使用一些現(xiàn)有的對(duì)象。某些配置選項(xiàng) (如 solrconfig 中的 dataDir 位置和 IndexWriter 相關(guān)設(shè)置) 不能通過簡(jiǎn)單的重新加載操作進(jìn)行更改和激活。

RELOAD Core 參數(shù)

core

內(nèi)核的名稱,如solr.xml<core>元素的“name”屬性中所列。該參數(shù)是必需的。

RENAME操作

該RENAME操作將更改Solr內(nèi)核的名稱。

admin/cores?action=RENAME&core=core-name&other=other-core-name

RENAME參數(shù)

core

要重命名的Solr核心的名稱。該參數(shù)是必需的。

other

Solr核心的新名稱。如果<solr>的persistent屬性為true,則新名稱將作為<core>屬性的name屬性被寫入solr.xml。該參數(shù)是必需的。

async

請(qǐng)求ID來跟蹤這個(gè)將被異步處理的動(dòng)作。

SWAP操作

SWAP自動(dòng)交換用于訪問兩個(gè)現(xiàn)有Solr核心的名稱。這可以用來將新內(nèi)容交換到生產(chǎn)中。先前的核心仍然可用,如有必要,可以交換回來。交換之后,每個(gè)核心將被另一個(gè)核心的名稱所知。

admin/cores?action=SWAP&core=core-name&other=other-core-name

注意:不要將 SWAP 與 SolrCloud 節(jié)點(diǎn)一起使用。它不受支持,可能會(huì)導(dǎo)致核心無法使用。

SWAP參數(shù)

core

要交換的核心之一的名稱。該參數(shù)是必需的。

other

要交換的核心之一的名稱。該參數(shù)是必需的。

async

請(qǐng)求ID來跟蹤這個(gè)將被異步處理的動(dòng)作。

UNLOAD操作

這個(gè)UNLOAD操作從Solr中刪除了一個(gè)核心?;顒?dòng)請(qǐng)求將繼續(xù)處理,但不會(huì)有新的請(qǐng)求發(fā)送到指定的內(nèi)核。如果核心以多個(gè)名稱注冊(cè),則只會(huì)刪除給定的名稱。

admin/cores?action=UNLOAD&core=core-name

該UNLOAD操作需要一個(gè)參數(shù)(core)來標(biāo)識(shí)要?jiǎng)h除的核心。如果<solr>的 persistent 屬性設(shè)置為true,則具有此name屬性的<core>元素將從solr.xml中移除。

注意:卸載SolrCloud集合中的所有核心會(huì)導(dǎo)致從ZooKeeper中刪除該集合的元數(shù)據(jù)。

UNLOAD參數(shù)

core

要?jiǎng)h除的核心的名稱。該參數(shù)是必需的。

deleteIndex

如果為true,則卸載核心時(shí)將刪除索引。默認(rèn)是false

deleteDataDir

如果為true,則刪除data目錄和所有的子目錄。默認(rèn)是false。

deleteInstanceDir

如果為true,則刪除與核心相關(guān)的所有內(nèi)容,包括索引目錄,配置文件和其他相關(guān)文件。默認(rèn)是false。

async

請(qǐng)求ID來跟蹤這個(gè)將被異步處理的動(dòng)作。

MERGEINDEXES 操作

該MERGEINDEXES操作將一個(gè)或多個(gè)索引合并到另一個(gè)索引。索引必須已經(jīng)完成提交,并且應(yīng)該鎖定寫入,直到合并完成或者生成的合并索引可能會(huì)損壞。目標(biāo)核心索引必須已經(jīng)存在,并且具有與將被合并到其中的一個(gè)或多個(gè)索引的兼容模式。合并完成后,還應(yīng)執(zhí)行目標(biāo)核心上的另一個(gè)提交:

admin/cores?action=MERGEINDEXES&core=new-core-name&indexDir=path/to/core1/data/index&indexDir=path/to/core2/data/index

在這個(gè)例子中,我們使用indexDir參數(shù)來定義源核的索引位置。該core參數(shù)定義了目標(biāo)索引。這種方法的好處是,我們可以合并任何可能與Solr核心無關(guān)的基于Lucene的索引。

或者,我們可以使用一個(gè)srcCore參數(shù),如下例所示:

admin/cores?action=mergeindexes&core=new-core-name&srcCore=core1-name&srcCore=core2-name

這種方法允許我們定義可能沒有與目標(biāo)內(nèi)核位于同一物理服務(wù)器上的索引路徑的內(nèi)核。但是,我們只能使用Solr核心作為源索引。這種方法的另一個(gè)好處是,如果寫入與源索引并行發(fā)生,那么我們沒有那么高的風(fēng)險(xiǎn)。

我們可以通過指定async參數(shù)并傳遞一個(gè) request-id 來異步運(yùn)行此調(diào)用。然后可以使用此ID來使用REQUESTSTATUS API檢查已提交的任務(wù)的狀態(tài)。

MERGEINDEXES參數(shù)

core

目標(biāo)核心/索引的名稱。該參數(shù)是必需的。

indexDir

多值的,將被合并的目錄。

srcCore

將被合并的多值源Core。

async

請(qǐng)求ID來跟蹤這個(gè)將被異步處理的動(dòng)作

SPLIT操作

該SPLIT操作將索引分成兩個(gè)或更多個(gè)索引。被拆分的索引可以繼續(xù)處理請(qǐng)求。拆分片段可以放在服務(wù)器文件系統(tǒng)的指定目錄中,也可以合并為正在運(yùn)行的Solr核心。

該SPLIT操作支持五個(gè)參數(shù),如下表所述。

SPLIT參數(shù)

core

要拆分的核心的名稱。該參數(shù)是必需的。

path

一個(gè)多值參數(shù),索引將被寫入的目錄路徑。這個(gè)參數(shù)或者targetCore必須被指定。如果指定了這個(gè)參數(shù),則不能使用該targetCore參數(shù)。

targetCore

一個(gè)多值參數(shù),一個(gè)索引將被合并到的目標(biāo)Solr核心。這個(gè)參數(shù)或者path必須被指定。如果指定了這個(gè)參數(shù),則不能使用該path參數(shù)。

ranges

以逗號(hào)分隔的十六進(jìn)制格式的哈希范圍列表。如果使用這個(gè)參數(shù),則不應(yīng)該使用split.key。有關(guān)如何使用此參數(shù)的示例,請(qǐng)參閱下面的SPLIT示例。

split.key

用于分割索引的關(guān)鍵。如果使用這個(gè)參數(shù),則不該使用ranges。有關(guān)如何使用此參數(shù)的示例,請(qǐng)參閱下面的SPLIT示例。

async

請(qǐng)求ID來跟蹤這個(gè)將被異步處理的動(dòng)作。

SPLIT示例

該core索引將被分成盡可能多的與path或targetCore參數(shù)的數(shù)量相同的部分。

兩個(gè)targetCore參數(shù)的用法:

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

這里core索引將被分成兩部分并合并成兩個(gè)targetCore索引。

使用兩個(gè)路徑參數(shù):

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

該core索引將被分成兩個(gè)部分,并寫入到指定的兩個(gè)目錄路徑。

與split.key參數(shù)一起使用:

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

這里所有的文件都有與split.key“A!” 相同的路由密鑰。將從core索引中拆分并寫入targetCore。

使用范圍參數(shù):

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

本示例使用在十六進(jìn)制中指定的哈希范圍0-500、501-1000 和1001-1500 的ranges參數(shù)。這里索引將被分成三部分,每個(gè)targetCore接收匹配指定哈希范圍的文件,即core1將得到哈希范圍為0-500的文檔,core2將接收哈希范圍為501-1000的文檔,最后,core3將接收帶有哈希范圍1001-1500的文檔。至少要指定一個(gè)哈希范圍。請(qǐng)注意,使用與路由密鑰哈希范圍相同的單個(gè)哈希范圍不等同于使用該split.key參數(shù),因?yàn)槎鄠€(gè)路由密鑰可以散列到相同的范圍。

在targetCore必須已經(jīng)存在,并且必須具有與core索引兼容的架構(gòu)。在分割之前,core索引會(huì)自動(dòng)調(diào)用一個(gè) commit。

該命令用作SPLITSHARD命令的一部分,但也可用于 non-cloud Solr內(nèi)核。當(dāng)針對(duì)沒有split.key參數(shù)的 non-cloud 核心使用時(shí),此操作將拆分源索引并交替分發(fā)其文檔,以便每個(gè)拆分文件包含相同數(shù)量的文檔。如果指定了split.key參數(shù),那么只有具有相同路由密鑰的文檔才會(huì)從源索引中分離出來。

REQUESTSTATUS 操作

請(qǐng)求已提交的異步CoreAdmin API調(diào)用的狀態(tài)。

admin/cores?action=REQUESTSTATUS&requestid=id

核心REQUESTSTATUS參數(shù)

REQUESTSTATUS命令只有一個(gè)參數(shù)。

requestid

用戶為異步請(qǐng)求定義了request-id。該參數(shù)是必需的。

下面的調(diào)用將返回已經(jīng)提交的異步CoreAdmin調(diào)用的狀態(tài)。

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

REQUESTRECOVERY 操作

該REQUESTRECOVERY操作手動(dòng)要求核心通過與領(lǐng)導(dǎo)者同步來恢復(fù)。這應(yīng)該被認(rèn)為是一個(gè)“專家級(jí)”的命令,應(yīng)該用于節(jié)點(diǎn)(SorlCloud副本)無法自動(dòng)激活的情況。

admin/cores?action=REQUESTRECOVERY&core=core-name

REQUESTRECOVERY參數(shù)

core

要重新同步的核心的名稱。該參數(shù)是必需的。

REQUESTRECOVERY示例

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

指定的核心可以通過管理UI擴(kuò)展適當(dāng)?shù)腪ooKeeper節(jié)點(diǎn)來找到。

以上內(nèi)容是否對(duì)您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號(hào)
微信公眾號(hào)

編程獅公眾號(hào)