怎么對SolrCloud集群Collection進行手動二次Sharding

本篇內容主要講解“怎么對SolrCloud集群Collection進行手動二次Sharding ”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么對SolrCloud集群Collection進行手動二次Sharding ”吧!

基于SolrCloud 4.3.1+Tomcat 7搭建了搜索服務器集群，一個Collection對應3個節點上的3個分片（Shard），同時包含對應分片的副本（Replica），此時，該 Collection一共有6000萬左右Document，平均每個分片大約接近2000萬。

SolrCloud集群節點的具體分布，如圖所示：

只有shard1有一個副本，并且位于不同的節點上。

隨著索引數據量的增長，如果我們的Collection的每個分片都不斷的增大，最后導致單個分片在搜索的時候，相應速度成為瓶頸，那么，我們 要考慮將每個分片再次進行分片。因為第一次系統規劃時已經設置好分片數量，所以每個分片所包含的Document數量幾乎是相同的，也就是說，再次分片 后，重新得到的分片的數量是原來的二倍。

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

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

這樣，就能告知ZooKeeper集群有新節點加入SolrCloud集群。

如上圖所示，我們打算將shard1進行二次手動分片，執行如下命令即可：

這個過程花費的時間比較長，而且可能會伴有如下異常相應信息：

[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 這個版本，實際真正的執行手動分片的動作已經在SolrCloud集群中進行，可以忽略這個異常。我們需要注意的是，在進行手動分片的時候，盡量不要在集 群操作比較頻繁的時候進行，例如，我就是在保持10個線程同時進行索引的過程中進行手動分片的，觀察服務器狀態，資源消費量比較大，而且速度很慢。

在執行手動分片的過程中，我們可以通過Web管理頁面。觀察當前集群中節點的狀態變化。

提交上面的命令以后，可以看到，集群中新增節點的狀態，如圖所示：

上面的狀態是“Recovering”，也就是在將shard1中分成兩個子分片，新增節點加入到集群，準備接收分片（或者對應的復制副本），如上圖可見，shard3和shard1在新增節點上分別增加了一個副本。

接續看集群狀態變化，如圖所示：

在 shard1所在節點（10.95.3.62）上，將shard1分成了兩個子分片：shard1_0和shard1_1，此時，在10.95.3.62 節點上有3個分片出于“Active”狀態。實際上，到目前為止，子分片shard1_0和shard1_1已經完全接管了shard1分片，只是沒有從 圖中自動離線退出，這個就需要我們在管理頁面你上手動“unload”掉不需要的shard。

這時，新得到的兩個子分片，并沒有處理之前shard1的兩個副本，他們也需要進行分片（實際上是重新復制新分片的副本），這個過程，如圖所示：

等待“Recovering”恢復完成以后，我們就可以看到進入“Active”狀態的節點圖，如圖所示：

手動分片的工作基本已經完成，這時候，如果繼續索引新的數據，shard1及其副本不會再接收請求，所以數據已經在再次分片的子分片上，請求也會發送到那些子分片的節點上，下面需要將之前的shard1及其分片unload掉，即退出集群，要處理的分片主要包含如下幾個：

一定不要操作失誤，否則可能會造成索引數據丟失的。unload這幾個分片以后，新的集群的節點分布，如圖所示：

shard1_0和shard1_1兩個新的分片，對應的副本，分別如下所示：

下面，我們對比一下，手動二次分片以后，各個節點上Document的數量，如下表所示：

可見，二次分片的shard1_1上面，Document數量相比于其它分片，十分不均。

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

到此，相信大家對“怎么對SolrCloud集群Collection進行手動二次Sharding ”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！