Solr 12 - 部署SolrCloud中遇到的问题 + 解决方法

目录

• 1 ZooKeeper管理配置文件的另一种方法
• 2 Solr服务不能访问
• 3 部分节点处于"Recovering"或"Gone"状态
• 4 Solr集群不稳定 + 监控界面无法显示
  • 4.1 问题一: 节点挂掉
  • 4.2 问题二: Solr Cloud监控界面无法显示
• 5 SolrCloud模式下, 启动Tomcat服务耗时太久
• 6 其他问题(尚未验证, 请存疑)
• 参考资料
• 版权声明

1 ZooKeeper管理配置文件的另一种方法

不通过Solr的example/scripts/cloud-scripts/zkcli.sh工具管理配置文件, 而是在Tomcat的catalina.sh文件中定义启动参数:

vim /data/solr-cloud/tomcat/apache-tomcat-8.0.53/bin/catalina.sh
# 在cygwin=false(大约109行)之前加入如下设置:
JAVA_OPTS="$JAVA_OPTS -DzkHost=zoo1:2181,zoo2:2181,zoo3:2181 -Dbootstrap_confdir=/data/solr-cloud/tomcat/solrhome/collection1/conf -Dcollection.configName=myconf -DnumShards=3"

(1) 参数解释:

① -Dnumshareds=3: 用来指定当前集群中分片数为3;

② -Dcollection.configName: 指定配置文件上传到ZooKeeper后的名字, 省略将默认为"configuration1";

③ -Dbootstrap_confdir: 指定所有的索引库都从此目录下的配置文件中同步配置, ZooKeeper将此路径下的配置文件上传至自己的配置中心进行统一管理;

④ -Djetty.port=8080: Jetty的监听端口, 要与Tomcat的端口保持一致, 用来实现集群间的通信, 如果配置错误, 集群将搜索不到数据.在这里(catalina.sh文件中)指定后, 就会覆盖solr.xml文件中的配置.

(2) 注意：

① -Dbootstrap_confdir、-DnumShards和-Dcollection.configName三个参数只需要在第一次运行SolrCloud模式时进行声明, 配置信息就回加载至ZooKeeper中; 以后如果更改了这些参数, 就需要再运行一次, ZooKeeper将会更新相关配置.

② 为了防止配置信息被改动, 建议只在某一台Tomcat的catalina.sh中加入这些参数, 其他集群的Tomcat中不添加.

2 Solr服务不能访问

(1) 问题描述:

启动Tomcat后, Tomcat管理页面可以显示, Solr服务却不能访问.

(2) 解决思路:

这里通过Tomcat的虚拟路径发布Solr服务, 稍有不慎就会出错. 可以查看$TOMCAT_HOME/logs下的日志信息, 查找错误原因.

(3) 博主遇到的是:

solr.xml文件没有添加到solrhome下, 导致Tomcat启动时无法加载Solr应用, 日志中提示缺少solr.xml文件, 上传此文件后重启Tomcat, 服务正常.

(4) 其他思路:

实在无法定位问题原因, 可从头再捋一遍部署过程. 上述过程博主已实际操作过了, 如有问题可留言或者邮件联系博主, 会回复你的~

3 部分节点处于"Recovering"或"Gone"状态

(1) 问题描述:

Solr Web管理页面出现了[Cloud]入口, 查看时发现部分节点未能正常启动.

(2) 解决思路:

博主在仔细捋了一遍部署过程后, 发现问题来自于ZooKeeper管理了2套配置文件: 因为部署过程比较坎坷, 在尝试通过solr-4.10.4/example/scripts/cloud-scripts/zkcli.sh命令删除配置文件失败后, 果断关掉Tomcat服务和ZooKeeper服务, 手动删除ZooKeeper/data/version-2和ZooKeeper/datalog/version-2文件, 注意不要删除data/myid. 这2个*/version-2目录存储的是ZooKeeper管理的配置文件信息.

删除后重新启动ZooKeeper集群, 再次通过solr-4.10.4/example/scripts/cloud-scripts/zkcli.sh命令上传配置文件, 然后启动各台Tomcat, 最后问题解决.

最后查得通过命令删除配置文件的方式如下:

[zk: localhost:2181(CONNECTED) 0] ls /
[configs, zookeeper, overseer, aliases.json, live_nodes, collections, overseer_elect, clusterstate.json]
[zk: localhost:2181(CONNECTED) 1] ls /configs
[myconf, conf]
[zk: localhost:2181(CONNECTED) 2] rmr /configs/conf
[zk: localhost:2181(CONNECTED) 3] ls /configs
[myconf]

4 Solr集群不稳定 + 监控界面无法显示

记录2个线上问题.

4.1 问题一: 节点挂掉

(1) 问题描述:

通过Solr Cloud从数据库导入大量数据(十亿级规模, 每条记录约70个字段);

导入时间超过2小时后, 挂掉了一部分节点 —— 由于磁盘写入速度较慢, 内存中的缓存无法及时置换到磁盘中, 导致索引创建超时, 进而引发ZooKeeper错误地将相关节点标记为失败 ⇒ 产生不一致.

主要报错信息有:

I was asked to wait on state down for shard5 in motor_collection on 10.1.2.3:8088_solr
but I still do not see the requested state.
I see state: active live:false leader from ZK:
Not available due to:  org.apache.solr.common.SolrException:
No registered leader was found after waiting for 0ms ,
collection:  motor_collection slice: shard5

org.apache.solr.common.SolrException:
ClusterState says we are the leader, but locally we don't think so.

(2) 解决思路:

这种情况下, 我们重启了Tomcat, 然后等待系统恢复后, 再次分批导入数据 —— 将数据规模限制到亿级.

因为已经成功导入了大部分数据, 直接删除ZooKeeper的数据再次部署Solr Cloud的成本太大, 所以没有轻易铲掉集群.

4.2 问题二: Solr Cloud监控界面无法显示

(1) 问题描述:

通过Solr Cloud查看集群中各个节点的状态时, 查看不到, 界面抛出如下错误信息:

Loading of "/solr/zookeeper?wt=json" failed (HTTP-Status 500)

(2) 问题分析:

① 通过ZooKeeper的客户端工具(zkCli.sh)查看集群中节点的信息、配置信息, 都存在, 只有异常节点的状态处于Recovering(恢复中);

② 通过Solr的原生API查看集合状态, 发现状态都正常, 参考博文:

Solr 13 - 通过SolrCloud的RESTful API对集群进行增删改查操作;

③ 最后定位到: 是ZooKeeper节点挂掉, 重新选举Leader后客户端缓存的Leader信息未及时更新, 从而产生脑裂现象, 导致版本信息的冲突. 异常信息有:

org.apache.zookeeper.KeeperException$ConnectionLossException:
KeeperErrorCode = ConnectionLoss for /overseer/queue

④ 导致ZooKeeper出现此问题的原因:

java.io.IOException: Packet len24038207 is out of range!
at org.apache.zookeeper.ClientCnxnSocket.readLength(ClientCnxnSocket.java:112)
at org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:79)
at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)

• 在ClientCnxnSocket.java的112行显示: packetLen=4096*1024, 也就是4MB. 说明客户端返回的配置文件的版本信息(包括日志信息)大小为4MB/条, 这在正常情况下是完全够用的(整个配置文件在10MB级别).
• 可一旦ZooKeeper出现异常, 将会产生大量的日志信息, 导致包大小超出范围的错误.
• 关注点应该放在ZooKeeper为何挂掉上. 这里是由于磁盘空间不足, 导致Solr节点不能及时写入索引, 进而导致ZooKeeper节点失败.

(3) 问题解决:

① 关闭ZooKeeper, 前往${ZK_HOME}/data/version-2/和${ZK_HOME}/datalog/version-2目录;

② 分别查看 快照文件(snapshot.xxx) 和 日志文件(log.xxx)的版本信息, 即后缀名的起始数字;

③ 备份所有ZooKeeper节点的数据, 防止出错后的恢复;

④ 根据时间推测上一个正确的版本数, 将其之后的版本数据删除掉(包括快照文件和日志文件), 需要同时删除所有ZooKeeper节点中相应版本的文件;

⑤ 重启ZooKeeper和Solr集群 ⇒ 问题解决!!!

5 SolrCloud模式下, 启动Tomcat服务耗时太久

(1) 问题描述:

重启Tomcat服务时, 需要很长的时间才能访问Solr集群.

(2) 问题解决:

修改任一分机下SolrCore的conf/solrconfig.xml文件, 注释约655-670行的监听器, 取消Tomcat的启动检查：

  <!-- QuerySenderListener takes an array of NamedList and executes a
       local query request for each NamedList in sequence.
    -->
  <listener event="newSearcher" class="solr.QuerySenderListener">
    <arr name="queries">
      <!--
         <lst><str name="q">solr</str><str name="sort">price asc</str></lst>
         <lst><str name="q">rocks</str><str name="sort">weight asc</str></lst>
        -->
    </arr>
  </listener>
  <listener event="firstSearcher" class="solr.QuerySenderListener">
    <arr name="queries">
      <lst>
        <str name="q">static firstSearcher warming in solrconfig.xml</str>
      </lst>
    </arr>
  </listener>

然后更新配置文件, 再次启动Tomcat服务, 问题得到解决.

6 其他问题(尚未验证, 请存疑)

(1) Solr 4.0的Admin UI中可以增加和删除Core, 如果Shard中的最后一个Core被删除, Shard是不会自动删除的, 这将导致集群出错;

(2) 某个Shard中所有的Core宕机了, 会导致不能继续插入新的记录, 查询也将出错;

(3) Core在Shard中扮演Leader或Replication, 是由Solr内部自动协调的, 目前没有找到人工干预的方法.

参考资料

Zookeeper客户端错误：Packet len* is out of range!

tomcat中搭建solr Cloud、日志、多Core以及常见问题

版权声明

作者: 马瘦风

出处: 博客园 马瘦风的博客

您的支持是对博主的极大鼓励, 感谢您的阅读.

本文版权归博主所有, 欢迎转载, 但请保留此段声明, 并在文章页面明显位置给出原文链接, 否则博主保留追究相关人员法律责任的权利.