怎么對(duì)SolrCloud集群Collection進(jìn)行手動(dòng)二次Sharding

本篇內(nèi)容主要講解“怎么對(duì)SolrCloud集群Collection進(jìn)行手動(dòng)二次Sharding ”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“怎么對(duì)SolrCloud集群Collection進(jìn)行手動(dòng)二次Sharding ”吧!

基于SolrCloud 4.3.1+Tomcat 7搭建了搜索服務(wù)器集群，一個(gè)Collection對(duì)應(yīng)3個(gè)節(jié)點(diǎn)上的3個(gè)分片（Shard），同時(shí)包含對(duì)應(yīng)分片的副本（Replica），此時(shí)，該 Collection一共有6000萬(wàn)左右Document，平均每個(gè)分片大約接近2000萬(wàn)。

SolrCloud集群節(jié)點(diǎn)的具體分布，如圖所示：

只有shard1有一個(gè)副本，并且位于不同的節(jié)點(diǎn)上。

隨著索引數(shù)據(jù)量的增長(zhǎng)，如果我們的Collection的每個(gè)分片都不斷的增大，最后導(dǎo)致單個(gè)分片在搜索的時(shí)候，相應(yīng)速度成為瓶頸，那么，我們 要考慮將每個(gè)分片再次進(jìn)行分片。因?yàn)榈谝淮蜗到y(tǒng)規(guī)劃時(shí)已經(jīng)設(shè)置好分片數(shù)量，所以每個(gè)分片所包含的Document數(shù)量幾乎是相同的，也就是說(shuō)，再次分片 后，重新得到的分片的數(shù)量是原來(lái)的二倍。

目前，SolrCloud不支持自動(dòng)分片，但是支持手動(dòng)分片，而且手動(dòng)分片后得到的新的分片所包含的Document數(shù)量有一定的差異（還不清 楚SolrCloud是否支持手動(dòng)分片后大致均分一個(gè)分片）。下面，我們看一下，在進(jìn)行手動(dòng)分片過(guò)程中，需要執(zhí)行哪些操作，應(yīng)該如何重新規(guī)劃整個(gè) SolrCloud集群。

首先，我增加了一個(gè)節(jié)點(diǎn)（slave6 10.95.3.67），把集群中原來(lái)的配置文件、solr-cloud.war及其Tomcat服務(wù)器都拷貝到這個(gè)新增的節(jié)點(diǎn)上，目的是將 10.95.3.62上的shard1再次分片，然后將再次得到分片運(yùn)行在新增的10.95.3.67節(jié)點(diǎn)上。啟動(dòng)新增節(jié)點(diǎn)的Tomcat服務(wù)器，它自動(dòng) 去連接ZooKeeper集群，此時(shí)ZooKeeper集群增加live_nodes數(shù)量，主要是通過(guò)在Tomcat的啟動(dòng)腳本中增加如下內(nèi)容：

這樣，就能告知ZooKeeper集群有新節(jié)點(diǎn)加入SolrCloud集群。

如上圖所示，我們打算將shard1進(jìn)行二次手動(dòng)分片，執(zhí)行如下命令即可：

這個(gè)過(guò)程花費(fèi)的時(shí)間比較長(zhǎng)，而且可能會(huì)伴有如下異常相應(yīng)信息：

[html] view plaincopy

1. <?xml version="1.0" encoding="UTF-8"?>  

2. <response>  

3. <lst name="responseHeader"><int name="status">500</int><int name="QTime">300138</int></lst><lst name="error"><str name="msg">splitshard the collection time out:300s</str><str name="trace">org.apache.solr.common.SolrException: splitshard the collection time out:300s  

4.      at org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:166)  

5.      at org.apache.solr.handler.admin.CollectionsHandler.handleSplitShardAction(CollectionsHandler.java:300)  

6.      at org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:136)  

7.      at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)  

8.      at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:608)  

9.      at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:215)  

10.      at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)  

11.      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)  

12.      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)  

13.      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)  

14.      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)  

15.      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)  

16.      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)  

17.      at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)  

18.      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)  

19.      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)  

20.      at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)  

21.      at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)  

22.      at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)  

23.      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)  

24.      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)  

25.      at java.lang.Thread.run(Thread.java:722)  

26. </str><int name="code">500</int></lst>  

27. </response>  

Solr 這個(gè)版本，實(shí)際真正的執(zhí)行手動(dòng)分片的動(dòng)作已經(jīng)在SolrCloud集群中進(jìn)行，可以忽略這個(gè)異常。我們需要注意的是，在進(jìn)行手動(dòng)分片的時(shí)候，盡量不要在集 群操作比較頻繁的時(shí)候進(jìn)行，例如，我就是在保持10個(gè)線程同時(shí)進(jìn)行索引的過(guò)程中進(jìn)行手動(dòng)分片的，觀察服務(wù)器狀態(tài)，資源消費(fèi)量比較大，而且速度很慢。

在執(zhí)行手動(dòng)分片的過(guò)程中，我們可以通過(guò)Web管理頁(yè)面。觀察當(dāng)前集群中節(jié)點(diǎn)的狀態(tài)變化。

提交上面的命令以后，可以看到，集群中新增節(jié)點(diǎn)的狀態(tài)，如圖所示：

上面的狀態(tài)是“Recovering”，也就是在將shard1中分成兩個(gè)子分片，新增節(jié)點(diǎn)加入到集群，準(zhǔn)備接收分片（或者對(duì)應(yīng)的復(fù)制副本），如上圖可見(jiàn)，shard3和shard1在新增節(jié)點(diǎn)上分別增加了一個(gè)副本。

接續(xù)看集群狀態(tài)變化，如圖所示：

在 shard1所在節(jié)點(diǎn)（10.95.3.62）上，將shard1分成了兩個(gè)子分片：shard1_0和shard1_1，此時(shí)，在10.95.3.62 節(jié)點(diǎn)上有3個(gè)分片出于“Active”狀態(tài)。實(shí)際上，到目前為止，子分片shard1_0和shard1_1已經(jīng)完全接管了shard1分片，只是沒(méi)有從 圖中自動(dòng)離線退出，這個(gè)就需要我們?cè)诠芾眄?yè)面你上手動(dòng)“unload”掉不需要的shard。

這時(shí)，新得到的兩個(gè)子分片，并沒(méi)有處理之前shard1的兩個(gè)副本，他們也需要進(jìn)行分片（實(shí)際上是重新復(fù)制新分片的副本），這個(gè)過(guò)程，如圖所示：

等待“Recovering”恢復(fù)完成以后，我們就可以看到進(jìn)入“Active”狀態(tài)的節(jié)點(diǎn)圖，如圖所示：

手動(dòng)分片的工作基本已經(jīng)完成，這時(shí)候，如果繼續(xù)索引新的數(shù)據(jù)，shard1及其副本不會(huì)再接收請(qǐng)求，所以數(shù)據(jù)已經(jīng)在再次分片的子分片上，請(qǐng)求也會(huì)發(fā)送到那些子分片的節(jié)點(diǎn)上，下面需要將之前的shard1及其分片unload掉，即退出集群，要處理的分片主要包含如下幾個(gè)：

一定不要操作失誤，否則可能會(huì)造成索引數(shù)據(jù)丟失的。unload這幾個(gè)分片以后，新的集群的節(jié)點(diǎn)分布，如圖所示：

shard1_0和shard1_1兩個(gè)新的分片，對(duì)應(yīng)的副本，分別如下所示：

下面，我們對(duì)比一下，手動(dòng)二次分片以后，各個(gè)節(jié)點(diǎn)上Document的數(shù)量，如下表所示：

可見(jiàn)，二次分片的shard1_1上面，Document數(shù)量相比于其它分片，十分不均。

SolrCloud也正在不斷的更新中，在后續(xù)的版本可能會(huì)更多地考慮到分片的問(wèn)題。另外，對(duì)于某個(gè)節(jié)點(diǎn)上的分片如果過(guò)大，影響了搜索效率，可以考慮另一種方案，就是重建索引，即使新增節(jié)點(diǎn)，重新索引再次重新分片，并均勻地分布到各個(gè)節(jié)點(diǎn)上。

到此，相信大家對(duì)“怎么對(duì)SolrCloud集群Collection進(jìn)行手動(dòng)二次Sharding ”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！