Thanks Michael, I am having a terrible time getting this non-sharded index up. Everything I try leads to a dead-end.
http://10.0.15.44:8511/solr/admin/collections?action=CREATE&name=tp&numShards=1&replicationFactor=5 it uses the solrconfig.xml from another core. That solrconfig.xml is deployed in conjunction with a solrcore.properties and the replication handler is configured with properties from that core's solrcore.properties file. The CREATE action uses the solrconfig.xml but not the properties so it fails. I tried to upload a different solrconfig.xml to zookeeper using the zkcli script -cmd upconfig and then to specify that config in the creation of the TP core like so http://10.0.15.44:8511/solr/admin/collections?action=CREATE&name=tp&numShards=1&replicationFactor=5&collection.configName=solrconfigTP.xml However, how can replication masters and slaves be configured with a single solrconfig.xml file unless each node is allowed to have its own config? This is a royal PITA. I may be wrong, but I think it is broken. Without a way to specify numShards per core in solr.xml, it seems impossible to have one sharded core and one non-sharded core. To be honest, I don't even care about replication. Why can't I specify a core that is non-sharded, non-replicated and have the exact same core on all five of my boxes? Thanks, Jim -----Original Message----- From: michael.boom [mailto:my_sky...@yahoo.com] Sent: Monday, November 18, 2013 7:14 AM To: solr-user@lucene.apache.org Subject: RE: SolrCloud question Hi, The CollectionAPI provides some more options that will prove to be very usefull to you: /admin/collections?action=CREATE&name=name&numShards=number&replicationFactor=number&maxShardsPerNode=number&createNodeSet=nodelist&collection.configName=configname Have a look at: https://cwiki.apache.org/confluence/display/solr/Collections+API Regarding your observations: 1. Completely normal, that's standard naming 2. When you created the collection you did not specify a configuration so the new collection will use the conf already stored in ZK. If you have more than one not sure which one will be picked as default. 3. You should be able to create replicas, by adding new cores on the other machines, and specifying the collection name and shard id. The data will then be replicated automatically to the new node. If you already tried that and get errors/problems while doing it provide some more details. As far as i know you should be able to move/replace the index data, as long as the source collection has the same config as the target collection. Afterwards you'll have to reload your core / restart the Solr instance - not sure which one will do it - most likely the latter. But it will be easier if you use the method described at point 3 above. Please someone correct me, if i'm wrong. ----- Thanks, Michael -- View this message in context: http://lucene.472066.n3.nabble.com/SolrCloud-question-tp4101266p4101675.html Sent from the Solr - User mailing list archive at Nabble.com. The information contained in this email message, including any attachments, is intended solely for use by the individual or entity named above and may be confidential. If the reader of this message is not the intended recipient, you are hereby notified that you must not read, use, disclose, distribute or copy any part of this communication. If you have received this communication in error, please immediately notify me by email and destroy the original message, including any attachments. Thank you.
