共計 5354 個字符，預(yù)計需要花費 14 分鐘才能閱讀完成。
本篇內(nèi)容主要講解“怎么對 SolrCloud 集群 Collection 進行手動二次 Sharding”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學(xué)習(xí)“怎么對 SolrCloud 集群 Collection 進行手動二次 Sharding”吧!
基于 SolrCloud 4.3.1+Tomcat 7 搭建了搜索服務(wù)器集群，一個 Collection 對應(yīng) 3 個節(jié)點上的 3 個分片（Shard），同時包含對應(yīng)分片的副本（Replica），此時，該 Collection 一共有 6000 萬左右 Document，平均每個分片大約接近 2000 萬。
SolrCloud 集群節(jié)點的具體分布，如圖所示：
只有 shard1 有一個副本，并且位于不同的節(jié)點上。
隨著索引數(shù)據(jù)量的增長，如果我們的 Collection 的每個分片都不斷的增大，最后導(dǎo)致單個分片在搜索的時候，相應(yīng)速度成為瓶頸，那么，我們 要考慮將每個分片再次進行分片。因為第一次系統(tǒng)規(guī)劃時已經(jīng)設(shè)置好分片數(shù)量，所以每個分片所包含的 Document 數(shù)量幾乎是相同的，也就是說，再次分片 后，重新得到的分片的數(shù)量是原來的二倍。
目前，SolrCloud 不支持自動分片，但是支持手動分片，而且手動分片后得到的新的分片所包含的 Document 數(shù)量有一定的差異（還不清 楚 SolrCloud 是否支持手動分片后大致均分一個分片）。下面，我們看一下，在進行手動分片過程中，需要執(zhí)行哪些操作，應(yīng)該如何重新規(guī)劃整個 SolrCloud 集群。
首先，我增加了一個節(jié)點（slave6 10.95.3.67），把集群中原來的配置文件、solr-cloud.war 及其 Tomcat 服務(wù)器都拷貝到這個新增的節(jié)點上，目的是將 10.95.3.62 上的 shard1 再次分片，然后將再次得到分片運行在新增的 10.95.3.67 節(jié)點上。啟動新增節(jié)點的 Tomcat 服務(wù)器，它自動 去連接 ZooKeeper 集群，此時 ZooKeeper 集群增加 live_nodes 數(shù)量，主要是通過在 Tomcat 的啟動腳本中增加如下內(nèi)容：
JAVA_OPTS= -server -Xmx4096m -Xms1024m -verbose:gc -Xloggc:solr_gc.log -Dsolr.solr.home=/home/hadoop/applications/solr/cloud/multicore -DzkHost=master:2188,slave1:2188,slave4:2188
這樣，就能告知 ZooKeeper 集群有新節(jié)點加入 SolrCloud 集群。
如上圖所示，我們打算將 shard1 進行二次手動分片，執(zhí)行如下命令即可：
curl http://master:8888/solr-cloud/admin/collections?action=SPLITSHARD collection=mycollection shard=shard1
這個過程花費的時間比較長，而且可能會伴有如下異常相應(yīng)信息：
[html] view plaincopy
?xml version= 1.0 encoding= UTF-8 ?
response
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
at org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:166)
at org.apache.solr.handler.admin.CollectionsHandler.handleSplitShardAction(CollectionsHandler.java:300)
at org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:136)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:608)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:215)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
/str int name= code 500 /int /lst
/response
Solr 這個版本，實際真正的執(zhí)行手動分片的動作已經(jīng)在 SolrCloud 集群中進行，可以忽略這個異常。我們需要注意的是，在進行手動分片的時候，盡量不要在集 群操作比較頻繁的時候進行，例如，我就是在保持 10 個線程同時進行索引的過程中進行手動分片的，觀察服務(wù)器狀態(tài)，資源消費量比較大，而且速度很慢。
在執(zhí)行手動分片的過程中，我們可以通過 Web 管理頁面。觀察當(dāng)前集群中節(jié)點的狀態(tài)變化。
提交上面的命令以后，可以看到，集群中新增節(jié)點的狀態(tài)，如圖所示：
上面的狀態(tài)是“Recovering”，也就是在將 shard1 中分成兩個子分片，新增節(jié)點加入到集群，準備接收分片（或者對應(yīng)的復(fù)制副本），如上圖可見，shard3 和 shard1 在新增節(jié)點上分別增加了一個副本。
接續(xù)看集群狀態(tài)變化，如圖所示：
在 shard1 所在節(jié)點（10.95.3.62）上，將 shard1 分成了兩個子分片：shard1_0 和 shard1_1，此時，在 10.95.3.62 節(jié)點上有 3 個分片出于“Active”狀態(tài)。實際上，到目前為止，子分片 shard1_0 和 shard1_1 已經(jīng)完全接管了 shard1 分片，只是沒有從 圖中自動離線退出，這個就需要我們在管理頁面你上手動“unload”掉不需要的 shard。
這時，新得到的兩個子分片，并沒有處理之前 shard1 的兩個副本，他們也需要進行分片（實際上是重新復(fù)制新分片的副本），這個過程，如圖所示：
等待“Recovering”恢復(fù)完成以后，我們就可以看到進入“Active”狀態(tài)的節(jié)點圖，如圖所示：
手動分片的工作基本已經(jīng)完成，這時候，如果繼續(xù)索引新的數(shù)據(jù)，shard1 及其副本不會再接收請求，所以數(shù)據(jù)已經(jīng)在再次分片的子分片上，請求也會發(fā)送到那些子分片的節(jié)點上，下面需要將之前的 shard1 及其分片 unload 掉，即退出集群，要處理的分片主要包含如下幾個：
mycollection_shard1_replica1
mycollection_shard1_replica_2
mycollection_shard1_replica_3
一定不要操作失誤，否則可能會造成索引數(shù)據(jù)丟失的。unload 這幾個分片以后，新的集群的節(jié)點分布，如圖所示：
shard1_0 和 shard1_1 兩個新的分片，對應(yīng)的副本，分別如下所示：
mycollection_shard1_0_replica1
mycollection_shard1_0_replica2
mycollection_shard1_0_replica3
mycollection_shard1_1_replica1
mycollection_shard1_1_replica2
mycollection_shard1_1_replica3
下面，我們對比一下，手動二次分片以后，各個節(jié)點上 Document 的數(shù)量，如下表所示：
分片 / 副本名稱所在節(jié)點文檔數(shù)量 mycollection_shard1_0_replica110.95.3.6218839290mycollection_shard1_0_replica210.95.3.6718839290mycollection_shard1_0_replica310.95.3.6118839290mycollection_shard1_1_replica110.95.3.62957980mycollection_shard1_1_replica210.95.3.61957980mycollection_shard1_1_replica310.95.3.67957980mycollection_shard2_replica110.95.3.6223719916mycollection_shard3_replica110.95.3.6123719739mycollection_shard3_replica110.95.3.6723719739
可見，二次分片的 shard1_1 上面，Document 數(shù)量相比于其它分片，十分不均。
SolrCloud 也正在不斷的更新中，在后續(xù)的版本可能會更多地考慮到分片的問題。另外，對于某個節(jié)點上的分片如果過大，影響了搜索效率，可以考慮另一種方案，就是重建索引，即使新增節(jié)點，重新索引再次重新分片，并均勻地分布到各個節(jié)點上。
到此，相信大家對“怎么對 SolrCloud 集群 Collection 進行手動二次 Sharding”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
