[
https://issues.apache.org/jira/browse/SOLR-10484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967990#comment-15967990
]
Christine Poerschke commented on SOLR-10484:
--------------------------------------------
bq. So is my original "property" idea really a role? ...
Good question, i had to go read up on the difference between property and role
actually :-)
*
https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-ADDREPLICAPROP:AddReplicaProperty
*
https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-ADDROLE:AddaRole
Logically, theoretically, there are four types of replicas:
* replicas which the "analytics" requests (continuing with your example) must
_not_ be sent to ('forbidden' replicas)
* replicas which the "analytics" requests should rather not be sent to
('disliked' replicas for lack of a better word)
* replicas which the "analytics" requests should ideally be sent to
('preferred' replicas)
* replicas which the "analytics" requests _must_ be sent to ('required'
replicas)
* replicas which are none of the above since they are not annotated
So if there are any 'required' replicas at all then "analytics" requests can
only be sent to those replicas. If there are no 'required' replicas but
'preferred' replicas then those will be used if available and only if they are
not available would the request be sent to a 'disliked' replica. In no
circumstances would the "analytics" requests go to a 'forbidden' replica.
Now, all of that is rather complex isn't it? And now what if we had "daily
analytics" requests and "weekly analytics" requests alongside the user-level
live traffic?
----
So it seems to me that yes your original idea is for a "role" that keeps a
replica from becoming active (or from being considered active).
And my thoughts are more along the lines of properties e.g.
{code}
<requestHandler name="/search" class="solr.SearchHandler" >
<shardHandlerFactory name="shardHandlerFactory"
class="solr.HttpShardHandlerFactory">
<!-- consider the 'tier' property when routing requests -->
<str name="replicaPriority.property">tier</str>
<!-- use a value of 1 for replicas that have no 'tier' property -->
<str name="replicaPriority.default">1</str>
<!-- send requests to tier 1 and tier 2 replicas, in that order i.e. prefer
tier 1 over tier 2 -->
<int name="replicaPriority.minimum">1</int>
<int name="replicaPriority.maximum">2</int>
</shardHandlerFactory>
</requestHandler>
<requestHandler name="/analytics" class="solr.SearchHandler" >
<shardHandlerFactory name="shardHandlerFactory"
class="solr.HttpShardHandlerFactory">
<!-- consider the 'tier' property when routing requests -->
<str name="replicaPriority.property">tier</str>
<!-- use a value of 1 for replicas that have no 'tier' property -->
<str name="replicaPriority.default">1</str>
<!-- send requests only to tier 3 replicas -->
<int name="replicaPriority.minimum">3</int>
<int name="replicaPriority.maximum">3</int>
</shardHandlerFactory>
</requestHandler>
{code}
In the above setup a replica could be taken out of (search and analytics) use
by giving it a {{tier}} value of (say) 4 or equally it could be set aside for
analytics use by temporarily giving it {{tier=3}} instead of {{tier=2}}
property.
----
So in short I think:
* "under_construction" role (this ticket, here)
* "replicaPriority.*" property (another ticket, another day)
PS: there already is a "construction"
[Slice.State|http://lucene.apache.org/solr/6_5_0/solr-solrj/org/apache/solr/common/cloud/Slice.State.html#CONSTRUCTION]
- not sure if "construction" and "under_construction" could be confused. An
alternative might be "dormant" role and alongside the existing "overseer" role
hopefully we'll never end up with a dormant overseer ...
> Create a new replica property that keeps a replica from becoming active.
> ------------------------------------------------------------------------
>
> Key: SOLR-10484
> URL: https://issues.apache.org/jira/browse/SOLR-10484
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
>
> See the user's list thread "Stopping a node from receiving any requests
> temporarily." for one example, but there are others. I can imagine operations
> people wanting to take a replica out of action for some time without
> affecting other replicas on that host.
> What do people think about having a property you could use with ADDREPLICA
> like "property.inactive" or something that kept the replica from coming up at
> all until the property was removed?
> DELETEREPLICAPROP could be used to remove it when operations was ready to
> have it become active.
> ADDREPLICAPROP could be used to add it to an active replica and should take
> that replica out of service.
> Whether we can piggy-back off of the core admin UNLOAD here I'm unclear on.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
