Check out some of the new documentation I added today: http://wiki.apache.org/solr/SolrCloud/#Command_Line_Util
Collections link with config sets following these rules: 1. When a collection starts, if there is only one config set, the collection will link to it. 2. If a collection starts and it shares the name of a config set, it will link to it. 3. Otherwise, the link has to be created manually - or by specifying it explicitly when creating the collection by HTTP API. boostrap_conf=true uploads a conf set for each core in solr.xml - and it links the conf sets to the collections by creating conf set names that match the collection names. If a collection has been linked to a config set, you have to manually update it to link it to a new config. You can do this with the above Command Line Util tool - one of the commands links collections to config sets. You can even make the links before starting Solr for the first time - when you do start Solr, as collections are started, it will find and use the link info you have created with the tool when names match. If you change the link while Solr is running you would want to reload all the cores in your collection to pick up the new config - you can do this with the Collections API: http://wiki.apache.org/solr/SolrCloud/#Managing_collections_via_the_Collections_API Mark Miller lucidworks.com On Aug 16, 2012, at 2:24 PM, Zulu Chas <zuluc...@hotmail.com> wrote: > > I am trying to set up a solrcloud/solr4.0.0-beta with multiple cores, > multiple shards, and a separate zookeeper process, but I think the exact > details are less important than the method of bootstrapping zookeeper with > the configs.Since I'm running zookeeper separately, I'd like to be able to > version solrcloud configs and drop them into zookeeper over time without > necessarily having to overwrite or immediately delete old ones. > After starting zookeeper using zkServer.sh start, I've been initially > bootstrapping it with: > > java -Dsolr.solr.home=instance1 -Djetty.port=8501 > -Djetty.home=$SOLR_HOME/solrcloud > -Dbootstrap_confdir=$SOLR_HOME/solrcloud/instance1/core0/conf > -Dcollection.configName=A01 -DnumShards=2 -DzkHost=localhost:2181 -jar > start.jar > > and then starting a second shard with: > > java -Dsolr.solr.home=instance2 -Djetty.port=8502 > -Djetty.home=$SOLR_HOME/solrcloud -Dcollection.configName=A01 > -DzkHost=localhost:2181 -jar start.jar > hoping that "-Dcollection.configName=A01" would do what I think it should do > :) > > But if I then iterate on the "A01" config and bootstrap a new config "A02" > (stopping all instances of solr first) but don't delete anything from > zookeeper: > > java -Dsolr.solr.home=instance1 -Djetty.port=8501 > -Djetty.home=$SOLR_HOME/solrcloud > -Dbootstrap_confdir=$SOLR_HOME/solrcloud/instance1/core0/conf > -Dcollection.configName=A02 -DnumShards=2 -DzkHost=localhost:2181 -jar > start.jar > I see it upload the configs: > > Aug 16, 2012 1:05:47 PM org.apache.solr.common.cloud.SolrZkClient > makePathINFO: makePath: /configs/A02/admin-extra.htmlAug 16, 2012 1:05:47 PM > org.apache.solr.common.cloud.SolrZkClient makePathINFO: makePath: > /configs/A02/admin-extra.menu-bottom.html > ... > ...so I had hoped it would use the given one in configName. Things seem to > run fine, but then if I do delete something from A01 to prove that it's using > the new config, I start to see error messages about things missing from A01 > ... showing me it's still using the old config: > > (delete /configs/A01/admin-extra.html in zkCli)Aug 16, 2012 2:04:01 PM > org.apache.solr.common.SolrException logSEVERE: > org.apache.solr.common.SolrException: Can not find: > /configs/A01/admin-extra.html at > org.apache.solr.handler.admin.ShowFileRequestHandler.showFromZooKeeper(ShowFileRequestHandler.java:155) > at > org.apache.solr.handler.admin.ShowFileRequestHandler.handleRequestBody(ShowFileRequestHandler.java:120)on > the console running instance1 > > I'm sure I'm just missing something simple here, but I didn't see any > reference online about re-bootstrapping. I also tried this adding > -Dbootstrap_conf=true [1] to each but that didn't make a difference. > -Chaz > [1] > http://mail-archives.apache.org/mod_mbox/lucene-dev/201205.mbox/%3cbb7ad9bf-389b-4b94-8c1b-bbfc4028a...@gmail.com%3E > >
