THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
“node2”: [“overseer”, “data”],
“node3”: [“data”]
}
GET /api/cluster/roles?node=node1
[“overseer”]
GET /api/cluster/roles?role=data
Code Block |
---|
["node2", "node3"] |
Internal representation in ZK
This is where the roles are internally published for anyone who wishes to see this.
/roles.json
{
“overseer” : [“node1”, “node2],
“data” : [“node1”, “node2”]
...
TBD
- Implementation details like these can be fleshed out in the PR
"roles.json"
already exists for this purpose, we can also consider adding roles as metadata for each entry in thelive_nodes
list.
Other notes
- Every time a node starts up with specified roles, the node assumes it is the correct role for that node and publishes those roles in ZK after successful startup.
- If a node is started with a -Dnode.roles parameter that doesn't have a data role, but it already has data hosting replicas on it, the startup fails with an error (and a hint indicating how to move replicas away from this replica).
- If a coordinator node is started with "data" role also, it fails to startup with a message indicating a node cannot both be coordinator and data node.
...