chatman commented on a change in pull request #403: URL: https://github.com/apache/solr/pull/403#discussion_r779833151
########## File path: solr/solr-ref-guide/src/node-roles.adoc ########## @@ -0,0 +1,198 @@ += Node Roles +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +A node in Solr is usually capable of performing various types of operations, e.g. hosting replicas, performing indexing and querying on them, collection management tasks etc. However, if someone wants to setup a cluster where these functionalities are isolated to certain dedicated nodes, then this can be achieved leveraging the concept of node roles. + +== Definitions + +=== Node role + +A role is a designation of a node that indicates that the node may perform a certain functionality that is governed by the role. + +=== Mode +Every role has a list of modes under which a node can be. It can be simple (e.g. `["on", "off"]`) or more granular (e.g. `["allowed", "preferred", "disallowed"]`). + +== Roles + +In order to specify role(s) for a node, one needs to start a Solr node with the following parameter. + +.Startup Parameter +[cols="1,2,1,1"] +|=== +|Parameter |Value |Required? | Default + +|solr.node.roles +|Comma separated list of roles (in the format: `<role>:<mode>`) for this node. +Examples: `-Dsolr.node.roles=data:on,overseer:allowed` or `-Dsolr.node.roles=overseer:preferred` +|No +|`data:on,overseer:allowed` +|=== + +[TIP] +==== +If a node has been started with no `solr.node.roles` parameter, it will be assumed to have the data role turned on and overseer role allowed on it. If you've never used roles before, you likely won't need to change anything in your startup parameters to accomodate the functionality associated with these roles. +==== + +.Supported roles +[cols="1,1"] +|=== +|Role |Modes + +|`data` +|on, off + +|`overseer` +|allowed, preferred, disallowed +|=== + +=== `data` role +A node with this role (in mode "on") can host shards and replicas for collections. + +=== `overseer` role +A node with this role can perform duties of an overseer node (unless mode is `disallowed`). When one or more nodes have the overseer role in `preferred` mode, the overseer leader will be elected from one of these nodes. In case no node is designated as a preferred overseer or no such node is live, the overseer leader will be elected from one of the nodes that have the overseer role in `allowed` mode. If all nodes that are designated with overseer role (allowed or preferred) are down, the cluster will be left without an overseer. + +== Example usage + +Sometimes, when the nodes in a cluster are under heavy querying or indexing load, the overseer leader node might be unable to perform collection management duties efficiently. It might be reasonable to have dedicated nodes to act as the overseer. Such an effect can be achieved as follows: + +* Most nodes (data nodes) in the cluster start with `-Dsolr.node.roles=data:on,overseer:allowed` (or with no parameter, since the default value for `solr.node.roles` is the same). Review comment: > Having a per role default (defaultIfAbsent) as well as a default for all roles when no role is specified (default value for solr.node.roles) is obviously more complex than only per role default (understanding how a Solr node behaves requires looking at two places to understand default behavior). There is no per role default. What used to be called "defaultIfAbsent" is now renamed as "modeWhenRoleIsAbsent", and is used for internal purposes anyway. > One can assume that a Solr deployment where solr.node.roles is overridden on each node (an advanced or "expert" cluster config) would be careful on upgrades and will not fall into the "ui" issue you mention. I don't think we should make such an assumption. An upgrade should come with no surprises to the user, unless he/she explicitly wants to opt into a role introduced in the new release. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
