lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master
Date Wed, 08 May 2019 17:00:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-13445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835756#comment-16835756
] 

ASF subversion and git services commented on SOLR-13445:
--------------------------------------------------------

Commit 8a1b966165339f017e0f1afb736b0afb939a0510 in lucene-solr's branch refs/heads/branch_8x
from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8a1b966 ]

SOLR-13445: Preferred replicas on nodes with same system properties as the query master


> Preferred replicas on nodes with same system properties as the query master
> ---------------------------------------------------------------------------
>
>                 Key: SOLR-13445
>                 URL: https://issues.apache.org/jira/browse/SOLR-13445
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Cao Manh Dat
>            Assignee: Cao Manh Dat
>            Priority: Major
>         Attachments: SOLR-13445.patch, SOLR-13445.patch, SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query request.
However, this presents a problem when running Solr in multiple availability zones.
> If one availability zone fails then it affects all Solr nodes because they will try to
connect to Solr nodes in the failed availability zone until the request times out. This can
lead to a build up of threads on each Solr node until the node goes out of memory. This results
in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be routed to
nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes get changed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message