[ https://issues.apache.org/jira/browse/SOLR-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arcadius Ahouansou updated SOLR-8146: ------------------------------------- Description: This is a simple proposal to allow more flexibility about which node SolrJ queries first. This is mainly to avoid unnecessary traffic in the network. For simplicity, let's say that we have a SolrSloud cluster deployed on 2 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. Initially, I thought it may be good to have Solr nodes tagged with rackID (snitch?) for matching the hosts. Note that this feature may have many usages such as SOLR-5501 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. was: This is a simple proposal to allow more flexibility about which node SolrJ queries first. This is mainly to avoid unnecessary traffic in the network. For simplicity, let's say that we have a SolrSloud cluster deployed on 2 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 operations should not be affected. Attached is a patch which is a work in progress. Initially, I thought it may be good to have Solr nodes tagged with rackID (snitch?) for matching the hosts. Note that this feature may have many usages such as SOLR-5501 Any comment would be very appreciated. Thanks. > Preferred SolrCloud node for SolrJ 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 > > > This is a simple proposal to allow more flexibility about which node SolrJ > queries first. > This is mainly to avoid unnecessary traffic in the network. > For simplicity, let's say that we have a SolrSloud cluster deployed on 2 > 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. > Initially, I thought it may be good to have Solr nodes tagged with rackID > (snitch?) for matching the hosts. > Note that this feature may have many usages such as SOLR-5501 > 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