solr4.2.1升级到solr4.7.2遇到的所有问题

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中而已。