1. 启动solr cloud ，启动到一半发现抛出这样的异常：ZkController.java第1087行代码
    "Could not find configName for collection " + collection + " found:" + configNames

           原因在于solr cloud 集群在启动的过程中需要加载zookeeper中的 collections core状态配置信息，因为在zk中还没有初始化，所以启动的时候发现配置信息是空的，solr连续尝试四次之后就会抛一个ZooKeeperException异常。

           解决办法是，在启动命令行中添加一个
    -Dcollection.configName=clusterconf     -Dbootstrap_confdir=./solr/collection1/conf   的配置项，solr在启动的时候就会自动将目标配置文件夹下的schema solrconfig 等配置信息同步到zookeeper节点上。完整的solr启动命令如下：

    Python代码   收藏代码
    1. java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.  
    2. configName=twoShardsTwoReplicasConf -DnumShards=2  
    3. -DzkHost=192.168.0.10:9983/baisui  -jar start.jar  
     
  2. 当应用启动好之后，solr core中已经有一份索引了，然后在solr管理页面（http://localhost/solr/#/collection1/query）上执行查询操作，抛了以下这个异常：
    C代码   收藏代码
    1. 2013-5-2 10:22:04 org.apache.solr.common.SolrException log  
    2. 严重: org.apache.solr.common.SolrException: no servers hosting shard:  
    3.         at org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:162)  
    4.         at org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:135)  
    5.         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)  
    6.         at java.util.concurrent.FutureTask.run(FutureTask.java:138)  
    7.         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)  
    8.         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)  
    9.         at java.util.concurrent.FutureTask.run(FutureTask.java:138)  
    10.         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)  
    11.         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)  
    12.         at java.lang.Thread.run(Thread.java:619)  
             首先需要解决的一个问题是solr启动使用的端口号是8983，但是现在运行的solr core所在tomcat容器中设定的solr端口号是80端口，当调用solr的shared查询时候，仍然会瓶装request url的时候用8983端口来拼装，所以在在shared查询的时候会发生服务不可用的错误，所以要在启动命令的参数中添加一个参数-Djetty.port=80， 说明一下，虽然是在tomcat容器中这个参数仍然是有效的。                     

             接下来再说如何解决上面那个异常，其实很简单，因为在初始化的时候设置了sharedNumber的数量为2，刚开始只启动了一台服务器，在查询的时候，在zookeeper中livenode节点中只有一台，还没有满足solrcloud最小shared为2的要求。所以在进行查询的时候抛出这个异常很正常，解决办法是再启动一个solr节点，启动命令是java -DzkHost=10.232.15.46:2181,10.232.36.130:2181/baisui -Djetty.port=80  -jar start.jar， 应用启动的时候自动会到zookeeper中的节点配置信息。第二个solr节点正常启动后，可以正常进行查询操作了。


            需要说明的是一个应用在初始化之后，sharedNumber数目就不能变了，但是 一个share中的副本是可以添加或者减少的。

  3. 删除cluster中的 Collection
              curl 'http://localhost:8983/solr/admin/collections?action=DELETE&name=userscollection'  试验了一下果然是可以删除的，但是在zookeepr的节点上查看还是刚刚生成的schema，solrconfig等配置文件还是存在的没有被删除掉。但是本地文件夹collection中的config 目录被删除了，重新启动solr container会出错。

               类似这样的维护solr应用的命令使用起来倒是挺方便的，但是感觉如果是线上应用的话这样调用起来也非常危险，一个不小心就把一个collection给删除了，那就摊上大事儿了

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生