[
https://issues.apache.org/jira/browse/SOLR-9251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15724425#comment-15724425
]
David Smiley commented on SOLR-9251:
------------------------------------
_Thanks for your help._ I realize that most apps/use-cases call for additional
replicas but mine doesn't -- it's an identified and acceptable limitation for
the confines of a slim operational budget. The system that can be reloaded if
need be.
To simplify this a bit, the example below uses a {{host}} tag instead of the
role. I don't see an error but I do see a shard going where I don't want it to
go. In particular, I want the "RT" shard on a specified host $rtHostName --
this worked okay. But once I got to the 3rd S<num> shard, I saw it on the host
rtHostName. I repeated this experiment after deleting the collection, and
switching up which host is the designated RT host, and it observed this time it
was the 4th numbered shard that was co-located with RT (the thing I'm trying to
avoid), not the 3rd. Interesting. The cluster I am trying this on has 3 Solr
nodes.
{noformat}curl -XPOST --fail "$SOLR_URL/admin/collections" -F action=CREATE -F
name="$COLLECTION" \
-F router.name=implicit -F shards=RT -F
createNodeSet="${rtHostName}:8983_solr" -F maxShardsPerNode=4 \
-F rule="shard:RT,host:$rtHostName" -F rule="shard:\!RT,host:\!$rtHostName"
// note escaping of the exclaimations to make Bash happy
curl -XPOST --fail "$SOLR_URL/admin/collections" -F action=CREATESHARD \
-F collection="$COLLECTION" -F shard=s1
//repeat above several times varying shard name: s1, s2, s3
{noformat}
> Allow a tag role:!overseer in replica placement rules
> -----------------------------------------------------
>
> Key: SOLR-9251
> URL: https://issues.apache.org/jira/browse/SOLR-9251
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 6.2
>
> Attachments: SOLR-9251.patch
>
>
> The reason to assign an overseer role to a node is to ensure that the node
> is exclusively used as overseer. replica placement should support tag called
> {{role}}
> So if a collection is created with {{rule=role:!overseer}} no replica should
> be created in nodes designated as overseer
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
