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内部自动协调的, 目前没有找到人工干预的方法.
参考资料
版权声明
作者: 马瘦风
出处: 博客园 马瘦风的博客
您的支持是对博主的极大鼓励, 感谢您的阅读.
本文版权归博主所有, 欢迎转载, 但请保留此段声明, 并在文章页面明显位置给出原文链接, 否则博主保留追究相关人员法律责任的权利.