Great, thanks for bringing closure to this!
oh, and one addendum. I wrote:
It'll probably be around forever since replication is used as a fall-back
Forget the "probably" there. In 7.x there are new replica types that
use this as their way of distributing the index, see the PULL replica
type
Hi Erick,
sorry for the slow reply. You are right, the information is not
persisted. Once I do a restart there is no information about the
replication source anymore. That explains why I could not find it
anywhere persisted ;-) I thought I had tested that last week but must
have not done so a
Does that persist even after you restart Solr on the target cluster?
And that clears up one bit of confusion I had, I didn't know how you
were having each shard on the target cluster use a different master URL
given they all use the same solrconfig file. I was guessing some magic with
system varia
Hi Erick,
that is actually the call I'm using :-)
If you invoke
http://solr_target_machine:port/solr/core/replication?command=details
after that you can see the replication status. But even after a Solr
restart the call still shows the replication relation and I would like
to remove this so t
Little known trick:
The fetchIndex replication API call can take any parameter you specify
in your config. So you don't have to configure replication at all on
your target collection, just issue the replication API command with
masterUrl, something like:
http://solr_target_machine:port/solr/core/
