No good ideas here with current Solr. I just raised SOLR-10484 for the generic ability to take a replica out of action (including the ADDREPLICA operation).
Your understanding is correct, Solr will route requests to active replicas. Is it possible that you can load the "from" core first _then_ add the replica that references it? Or do they switch roles? Best, Erick On Wed, Apr 12, 2017 at 7:39 AM, Callum Lamb <cl...@mintel.com> wrote: > Forgot to mention. We're using solr 5.5.2 in Solr cloud mode. Everything is > single sharded at the moment as the collections are still quite small. > > On Wed, Apr 12, 2017 at 3:30 PM, Callum Lamb <cl...@mintel.com> wrote: > >> We have a Solr cluster that still takes queries that join between cores (I >> know, bad). We can't change that anytime soon however and I was hoping >> there was a band-aid I could use in the mean time to make deployments of >> new nodes cleaner. >> >> When we want to add a new node to cluster we'll have a brief moment in >> time where one of the cores in that join will be present, but the other >> won't. >> >> My understanding is that even if you stop requests from reaching the new >> Solr node with haproxy, Solr can can route requests between nodes on it's >> own behind haproxy. We've also noticed that this internal Solr routing is >> not aware of the join in the query and will route a request to a core that >> joins to another core even if the latter is not present yet (Causing the >> query to fail). >> >> Until we eliminate all the joins, we want to be able to have a node we can >> do things to, but *gaurentee* it won't receive any requests until we decide >> it's ready to take requests. Is there an easy way to do this? We could try >> stopping the Solr's from talking to each other at the network level but >> this seems iffy to me and might cause something weird to happen. >> >> Any ideas? >> >> >> > > -- > > Mintel Group Ltd | 11 Pilgrim Street | London | EC4V 6RN > Registered in England: Number 1475918. | VAT Number: GB 232 9342 72 > > Contact details for our other offices can be found at > http://www.mintel.com/office-locations. > > This email and any attachments may include content that is confidential, > privileged > or otherwise protected under applicable law. Unauthorised disclosure, > copying, distribution > or use of the contents is prohibited and may be unlawful. If you have > received this email in error, > including without appropriate authorisation, then please reply to the > sender about the error > and delete this email and any attachments. >
