Hi Shawn, Thanks for your reply. I removed hardcoded dataDir from solr.xml and created different solr.xml per Solr instance. After these changes, the SPLITSHARD command returned successfully.
Before splitting, shard1 was pointing to HOST1 and HOST2 (leader and replica) and shard2 was pointing to HOST3 and HOST4. I splited shard1 and now sharc1_0 and shard1_1 got created. But these two new shards are pointing to HOST1 and HOST3. I think it should point to HOST1 and HOST2 since the shard1 was originally pointing to HOST1 and HOST2. The solr cloud still shows me shard1 after splitting it. I will restart the cloud and see if it goes away. Thanks! -----Original Message----- From: Shawn Heisey [mailto:s...@elyograg.org] Sent: Friday, June 21, 2013 5:38 PM To: solr-user@lucene.apache.org Subject: Re: SPLITSHARD throws error On 6/21/2013 3:06 PM, Joshi, Shital wrote: > > This is what we have in solr.xml. > > > <solr persistent="true"> > <cores adminPath="/admin/cores" defaultCoreName="collection1" > host="${host:}" hostPort="${jetty.port:8983}" > hostContext="${hostContext:solr}" zkClientTimeout="${zkClientTimeout:15000}"> > <core name="collection1" instanceDir="collection1" > dataDir="${solr.data.dir:}" shard="${shard:}" /> > </cores> > </solr> > > > We use one solr.xml and pass dataDir, shard as java system property. (e.g.: > -Dsolr.data.dir=$HOME/solr_data/solr6 > -Dsolr.ulog.dir=$HOME/solr_data/solr6_tranlog -DnumShards=5 -Dshard=shard1) There's the problem. You can't hard-code dataDir with SolrCloud unless it's a relative path. It's trying to share the same dataDir between the two cores that it's creating from the old one. dataDir defaults to ${instanceDir}/data. The solr.xml file will get modified when you use the collections and core admin APIs, and each server will get different modifications, so sharing it between different Solr servers is not a good idea. Thanks, Shawn
