Hi,

you are right, I have removed "collection1" from the solr.xml but set defaultCoreName="storage".

Also this works in 4.0 but won't in 4.2.1, any clues ?

Kind Regards
Alexander

Am 2013-04-08 20:06, schrieb Joel Bernstein:
The scenario above needs to have collection1 removed from the solr.xml to
work. This, I believe, is the "Empty Solr" scenario that you are talking
about. If you don't remove collection1 from solr.xml on all the solr
instances, they will get tripped up on collection1 during these steps.

If you startup with collection1 in solr.xml it's best to startup the
initial Solr instance with the bootstrap-conf parameter so Solr can
properly create this collection.


On Mon, Apr 8, 2013 at 1:12 PM, Joel Bernstein <joels...@gmail.com> wrote:

The steps that I use to setup the collection are slightly different:


1) Start zk and upconfig the config set. Your approach is same.
2) Start appservers with Solr zkHost set to the zk started in step 1.
3) Use a core admin command to spin up a new core and collection.


http://app01/solr/admin/cores?action=CREATE&name=storage-core&collection=storage&numShards=1&collection.configName=storage-conf<http://app03/solr/admin/collections?action=CREATE&name=storage&numShards=1&replicationFactor=2&collection.configName=storage-conf>
&shard=shard1

This will spin up the new collection and initial core. I'm not using a
replication factor because the following commands manually bind the
replicas.

4) Spin up replica with a core admin command:

http://app02/solr/admin/cores?action=CREATE&name=storage-core&collection=storage&;<http://app03/solr/admin/collections?action=CREATE&name=storage&numShards=1&replicationFactor=2&collection.configName=storage-conf>
shard=shard1

5) Same command as above on the 3rd server to spin up another replica.

This will spin up a new core and bind it to shard1 of the storage
collection.





On Mon, Apr 8, 2013 at 9:34 AM, A.Eibner <a_eib...@yahoo.de> wrote:

Hi,

I have a problem with setting up my solr cloud environment (on three
machines).
If I want to create my collections from scratch I do the following:

*) Start ZooKeeper on all machines.

*) Upload the configuration (on app02) for the collection via the
following command:
     zkcli.sh -cmd upconfig --zkhost app01:4181,app02:4181,app03:**4181
--confdir config/solr/storage/conf/ --confname storage-conf

*) Linking the configuration (on app02) via the following command:
     zkcli.sh -cmd linkconfig --collection storage --confname storage-conf
--zkhost app01:4181,app02:4181,app03:**4181

*) Start Tomcats (containing Solr) on app02,app03

*) Create Collection via:
http://app03/solr/admin/**collections?action=CREATE&**
name=storage&numShards=1&**replicationFactor=2&**
collection.configName=storage-**conf<http://app03/solr/admin/collections?action=CREATE&name=storage&numShards=1&replicationFactor=2&collection.configName=storage-conf>

This creates the replication of the shard on app02 and app03, but neither
of them is marked as leader, both are marked as DOWN.
And after wards I can not access the collection.
In the browser I get:
"SEVERE: org.apache.solr.common.**SolrException: no servers hosting
shard:"

In the log files the following error is present:
SEVERE: Error from shard: app02:9985/solr
org.apache.solr.common.**SolrException: Error CREATEing SolrCore
'storage_shard1_replica1':
         at org.apache.solr.client.solrj.**impl.HttpSolrServer.request(**
HttpSolrServer.java:404)
         at org.apache.solr.client.solrj.**impl.HttpSolrServer.request(**
HttpSolrServer.java:181)
         at org.apache.solr.handler.**component.HttpShardHandler$1.**
call(HttpShardHandler.java:**172)
         at org.apache.solr.handler.**component.HttpShardHandler$1.**
call(HttpShardHandler.java:**135)
         at java.util.concurrent.**FutureTask$Sync.innerRun(**
FutureTask.java:334)
         at java.util.concurrent.**FutureTask.run(FutureTask.**java:166)
         at java.util.concurrent.**Executors$RunnableAdapter.**
call(Executors.java:471)
         at java.util.concurrent.**FutureTask$Sync.innerRun(**
FutureTask.java:334)
         at java.util.concurrent.**FutureTask.run(FutureTask.**java:166)
         at java.util.concurrent.**ThreadPoolExecutor.runWorker(**
ThreadPoolExecutor.java:1110)
         at java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
ThreadPoolExecutor.java:603)
         at java.lang.Thread.run(Thread.**java:722)
Caused by: org.apache.solr.common.cloud.**ZooKeeperException:
         at org.apache.solr.core.**CoreContainer.registerInZk(**
CoreContainer.java:922)
         at org.apache.solr.core.**CoreContainer.registerCore(**
CoreContainer.java:892)
         at org.apache.solr.core.**CoreContainer.register(**
CoreContainer.java:841)
         at org.apache.solr.handler.admin.**CoreAdminHandler.**
handleCreateAction(**CoreAdminHandler.java:479)
         ... 19 more
Caused by: org.apache.solr.common.**SolrException: Error getting leader
from zk for shard shard1
         at org.apache.solr.cloud.**ZkController.getLeader(**
ZkController.java:864)
         at org.apache.solr.cloud.**ZkController.register(**
ZkController.java:776)
         at org.apache.solr.cloud.**ZkController.register(**
ZkController.java:727)
         at org.apache.solr.core.**CoreContainer.registerInZk(**
CoreContainer.java:908)
         ... 22 more
Caused by: java.lang.**InterruptedException: sleep interrupted
         at java.lang.Thread.sleep(Native Method)
         at org.apache.solr.cloud.**ZkController.getLeaderProps(**
ZkController.java:905)
         at org.apache.solr.cloud.**ZkController.getLeaderProps(**
ZkController.java:875)
         at org.apache.solr.cloud.**ZkController.getLeader(**
ZkController.java:839)
         ... 25 more

I have attached a minimal set of configuration files which are needed to
replicate this error, also containing the log files for the commands I have
run in the order above.

I use the following versions of:
Solr: 4.2.1
ZooKeeper: 3.4.5
Tomcat 7.0.27

app01: ZooKeeper
app02: ZooKeeper, Solr (in Tomcat)
app03: ZooKeeper, Solr (in Tomcat)

The same procedure does work if I use Solr 4.0, but the BUG (
https://issues.apache.org/**jira/browse/SOLR-3939<https://issues.apache.org/jira/browse/SOLR-3939>
) prevents me from using 4.0 in this scenario.

If you need anything else, please just say so.

Thanks for your help

Kind Regards
Alexander




--
Joel Bernstein
Professional Services LucidWorks





Reply via email to