Why don't you think splitting the shards will do what you need? Admittedly it will have to be applied to each shard and will double the number of shards you have, that's the current limitation. At the end, though, you will have 4 shards when you used to have 2 and you can move them around to whatever hardware you can scrape up.
This assumes you're using the default compositeId routing scheme and not implicit routing. If you are using compositeId there is no provision to add another shard. As far as SOLR-5025 is concerned, nobody's working on that that I know of. I have to ask though whether you've tuned your existing machines. How many docs are on each? Why do you think you need more shards? Query speed? OOMs? Java heaps getting too big? Best, Erick On Fri, Apr 15, 2016 at 10:50 PM, Jay Potharaju <jspothar...@gmail.com> wrote: > I found ticket https://issues.apache.org/jira/browse/SOLR-5025 which talks > about sharding in solrcloud. Are there any plans to address this issue in > near future? > Can any of the users on the forum comment how they are handling this > scenario in production? > Thanks > > On Fri, Apr 15, 2016 at 4:28 PM, Jay Potharaju <jspothar...@gmail.com> > wrote: > >> Hi, >> I have an existing collection which has 2 shards, one on each node in the >> cloud. Now I want to split the existing collection into 3 shards because of >> increase in volume of data. And create this new shard on a new node in the >> solrCloud. >> >> I read about splitting a shard & creating a shard, but not sure it will >> work. >> >> Any suggestions how are others handling this scenario in production. >> -- >> Thanks >> Jay >> >> > > > > -- > Thanks > Jay Potharaju
