On 6/15/2018 11:08 AM, Oakley, Craig (NIH/NLM/NCBI) [C] wrote: > If I start with a collection X on two nodes with one shard and two replicas > (for redundancy, in case a node goes down): a node on host1 has > X_shard1_replica1 and a node on host2 has X_shard1_replica2: when I try > SPLITSHARD, I generally get X_shard1_0_replica1, X_shard1_1_replica1 and > X_shard1_0_replica0 all on the node on host1 with X_shard1_1_replica0 sitting > alone on the node on host2. If host1 were to go down at this point, shard1_0 > would be unavailable.
https://lucene.apache.org/solr/guide/6_6/collections-api.html#CollectionsAPI-splitshard That documentation says "The new shards will have as many replicas as the original shard." That tells me that what you're seeing is not matching the *intent* of the SPLITSHARD feature. The fact that you get *one* of the new shards but not the other is suspicious. I'm wondering if maybe Solr tried to create it but had a problem doing so. Can you check for errors in the solr logfile on host2? If there's nothing about your environment that would cause a failure to create the replica, then it might be a bug. > Is there a way either of specifying placement or of giving hints that > replicas ought to be separated? It shouldn't be necessary to give Solr any parameters for that. All nodes where the shard exists should get copies of the new shards when you split it. > I am currently running Solr6.6.0, if that is relevant. If this is a provable and reproducible bug, and it's still a problem in the current stable branch (next release from that will be 7.4.0), then it will definitely be fixed. If it's only a problem in 6.x, then I can't guarantee that it will be fixed. That's because the 6.x line is in maintenance mode, which means that there's a very high bar for changes. In most cases, only changes that meet one of these criteria are made in maintenance mode: * Fixes a security bug. * Fixes a MAJOR bug with no workaround. * Fix is a very trivial code change and not likely to introduce new bugs. Of those criteria, generally only the first two are likely to prompt an actual new software release. If enough changes of the third type accumulate, that might prompt a new release. My personal opinion: If this is a general problem in 6.x, it should be fixed there. Because there is a workaround, it would not be cause for an immediate new release. Thanks, Shawn
