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.
