[ https://issues.apache.org/jira/browse/SOLR-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081120#comment-15081120 ]
Noble Paul commented on SOLR-8146: ---------------------------------- bq.in order to use the preferredNodes snitch, one will have to add that snitch to the collection. Is this correct? well, no. The implicit snitches are available to all collections. A snitch just has to say that I can provide values for a particular tag . Using regex is not really possible in the current design . It is only possible to provide discrete values. or ranges. Lets assume an ip address 192.93.255.255 . It is possible for a Snitch to provide values such as ip_1 = 192 ip_2 = 93 ip_3 = 255 ip_4 = 255 In this case you can provide a rule which says {{preferredNodes=ip_1:192,ip_2:93}} This means it will choose only nodes {{192.93.\*.\*}} This can be a part of the {{ImplicitSnitch}} itself. The implicitSnitch can provide values for tags {{ip_1}}, {{ip_2}}. {{ip_3}}, {{ip_4}} and for ip v6 it can provide values for {{ip_5}} and {{ip_6}} as well > Allowing SolrJ CloudSolrClient to have preferred replica for query/read > ----------------------------------------------------------------------- > > Key: SOLR-8146 > URL: https://issues.apache.org/jira/browse/SOLR-8146 > Project: Solr > Issue Type: New Feature > Components: clients - java > Affects Versions: 5.3 > Reporter: Arcadius Ahouansou > Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch > > > h2. Backgrouds > Currently, the CloudSolrClient randomly picks a replica to query. > This is done by shuffling the list of live URLs to query then, picking the > first item from the list. > This ticket is to allow more flexibility and control to some extend which > URLs will be picked up for queries. > Note that this is for queries only and would not affect update/delete/admin > operations. > h2. Implementation > The current patch uses regex pattern and moves to the top of the list of URLs > only those matching the given regex specified by the system property > {code}solr.preferredQueryNodePattern{code} > Initially, I thought it may be good to have Solr nodes tagged with a string > pattern (snitch?) and use that pattern for matching the URLs. > Any comment, recommendation or feedback would be appreciated. > h2. Use Cases > There are many cases where the ability to choose the node where queries go > can be very handy: > h3. Special node for manual user queries and analytics > One may have a SolrCLoud cluster where every node host the same set of > collections with: > - multiple large SolrCLoud nodes (L) used for production apps and > - have 1 small node (S) in the same cluster with less ram/cpu used only for > manual user queries, data export and other production issue investigation. > This ticket would allow to configure the applications using SolrJ to query > only the (L) nodes > This use case is similar to the one described in SOLR-5501 raised by [~manuel > lenormand] > h3. Minimizing network traffic > > For simplicity, let's say that we have a SolrSloud cluster deployed on 2 (or > N) separate racks: rack1 and rack2. > On each rack, we have a set of SolrCloud VMs as well as a couple of client > VMs querying solr using SolrJ. > All solr nodes are identical and have the same number of collections. > What we would like to achieve is: > - clients on rack1 will by preference query only SolrCloud nodes on rack1, > and > - clients on rack2 will by preference query only SolrCloud nodes on rack2. > - Cross-rack read will happen if and only if one of the racks has no > available Solr node to serve a request. > In other words, we want read operations to be local to a rack whenever > possible. > Note that write/update/delete/admin operations should not be affected. > Note that in our use case, we have a cross DC deployment. So, replace > rack1/rack2 by DC1/DC2 > Any comment would be very appreciated. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org