1、建立colletion經常timeout，因為solr.xml配置的超時時間太短。配置時間變大，為了適用所有node，將solr.xml上傳到zk，命令：

sh zkcli.sh  -zkhost  zookeeper1:42181/on_other_47 -cmd putfile /solr.xml $name然後配置：

-Dsolr.solrxml.location=zookeeper就可以每個node都拿到。我們超時配置成5s其實有時也會出現timeout，但其實colletion已經生成。

2、delete collection異常，首先要保證colletion的狀態都是正常的，再做delete操作，並且最好加上&deleteInstanceDir=true，這樣下次建立不會失敗。4.2.1其實有時候出現節點down然後起不來的問題，其實只要根據clusterstate.json修改solr.xml和solr資料夾下的replica目錄對應即可。

3、刪除zk叢集資訊的時候，出現刪除不了節點的情況，delete和rmr都不行，原因：有一臺solr node沒有關掉，jetty假死，zk無法清除overseer。最好還是不要去操作zookeeper節點去幹預叢集，比如修改clusterstate.json。

4、新的solr4.7.0使用的是log4j而不是slf4j，編寫zk上傳指令碼時，要換成新的jar包，並且在java編譯環境裡面加上log4j.properties檔案路徑引數。

如：$JVM  -classpath "$sdir/../lib47/*" -Dlog4j.configuration="file:./log4j.properties" org.apache.solr.cloud.ZkCLI ${1+"

5、buffers/cache 佔用過多，導致Linux kill掉節點；在記憶體或者硬碟不充足的情況下，一臺機不要起過多的節點，導致記憶體使用完，因為當前solr會使用記憶體對映，導致buffer/cache全部使用完。

6、建立userRecommendIds失敗時，居然首先會在node上面建立core，如果不刪除掉，下次建立有可能失敗。解決方案：手動刪掉建立collection失敗的時候建立的core。而且solr4.7.2 的solr.xml沒有core的資訊，它的資訊在每個replication中的core.properties檔案中；而solr4.2在solr.xml，所有core資訊都在一起，需要一併去掉。

7、solr4.7.2自帶了hadoop包，有4個，如果你的solr4.2.1上有hadoop相關擴充套件，會報錯。比如我們的handler裡有取hbase資料，目前做法是，這一部分的叢集暫不升級。

8、編寫solr擴充套件時要注意solr自帶了很多包，有可能會有衝突，比如上面說的hadoop包，還有httpclient的包等。

9、jstat -gccause pid 1000來監控GC情況很方便，可發現很多問題；目前我們使用jdk最新版，新的GC演算法。

10、solr4.7.2的optimize操作非常緩慢，因為它採用的是序列的。我們目前針對大的索引做了優化，建立時採用http方式並行優化，並且擴充套件實現離線索引。

11、實踐發現某個collection主分片所在節點A機和其副本所在節點B機會保持一個長連線，TCP協議的，CLOSE_WAIT狀態。這樣有可能發生一個小概率事件，即你再起一個node的時候，發現端口占用了，因為剛好被這個長連線隨機選中佔用。

12、solr4.7.2分詞相關的類有所改變，需要對照原始碼類進行修改，比如過濾器Factory類等。

13、將舊的建索引程式改成新的時候，報錯：Invalid UTF-8 middle byte 0xe0，位置是delete操作*:*。在solr4.2.1中，update配置的handler是：

<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />沒有問題；但是solr4.7.2中就不行了，必須配置：

<requestHandler name="/update" class="solr.UpdateRequestHandler" />

14、4.7.2不支援BigInteger和BigDecimal型別資料提交，但是我們之前4.2.1是支援的，所以認為這是一個Bug；確實也有人在jira上提交這個Bug，不過是說DataInputHandler這個模組的。

15、solr4.7.2的clusterstate.json的replication狀態不會改變，而且ClusterState.getCollections獲取的也是狀態始終不變的。但是有一個可以解決這個問題，結合liveNodes即可判斷，但是結果就是除了ACTIVE就是DOWN這2中而已。