THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- “data” role: A node with this role can host data hosting replicas. By default, this is the case for all nodes.
- “overseer” role: A node with this role indicates that this node is a preferred overseer. When one or more such nodes are live, Solr guarantees that one of those nodes become the overseer. Note: There is no change proposed to the OVERSEER role as it exists today, except that it can now be enabled using startup params, and ADDROLE/REMOVEROLE are deprecated.
Roles that might be introduced in future (specifics are outside the scope of this SIP, except for examples):
...
Startup parameter (sysprop)
Parameter | Value | Required? | Default |
solr.node.roles | Comma separated list of roles for this node, with each role in lowercase, and no repetitions in the list. | No | data
|
Examples:
- Preferred overseer node with no data (dedicated overseer):
-Dsolr.node.roles=overseer - Preferred overseer with data:
-Dsolr.node.roles=overseer,data - Coordinator node (preview for upcoming feature):
-Dsolr.node.roles=coordinator
...
To Read the values use HTTP GET
GET /api/cluster/roles
Sample output: {
“node1”: [“overseer”],
“node2”: [“overseer”, “data”],
“node3”: [“data”]
}
GET /api/cluster/roles/supported
Sample output: [“overseer”, "data"]
Description: Which roles do this current Solr cluster support?
GET /api/cluster/roles/nodes/node1${nodename}
Sample output: [“overseer”]
GET /api/cluster/roles/data${rolename}
Sample output: ["node2", "node3"]
Internal representation in ZK
...