Page History

...

For example:
- Nodes with "data" role MAY host replicas (i.e. nodes without MAY NOT)
- Nodes with (UPCOMING FUTURE ROLE) "zk" role MAY run zk (i.e. nodes without the role MAY NOT)
- Nodes with (IMAGINARY EXAMPLE) "worker" role MAY execute streaming map/reduce work
- Nodes with (IMAGINARY EXAMPLE) "ingest" role MAY run Tika parsing, OCR, data prepping etc

...

• All nodes join live_nodes, as is the case today
• ZK structure for roles:
  • • /node_roles
      • overseer
        znode data: { .. /* some configs for overseer role */ ..}
        • nodes
          
          •  solr1_8983 (ephemeral node)
            
          •  solr2_8983 (ephemeral node)
          •  solr3_8983 (ephemeral node)
        • data
          znode data: { .. /* some configs for data role */ ..}
          • nodes
            
            •  solr4_8983 (ephemeral node)
            •  solr5_8983 (ephemeral node)
            •  solr6_8983 (ephemeral node)
            •  solr7_8983 (ephemeral node)
            • ...
          • coordinator (example of a future role)
            znode data: {.. /* configs.. */}
            • nodes
              
              • solrcoord1_8983 (ephemeral node)
              • ...

      Roles During Application Lifecycle:

      ...

      2) If at startup, sysprops are present:

      ...

      • Yes: Role is published as ephemeral nodes in ZK.

      ...

      • No: Roles are configured to export the default set of roles (at the time of this SIP, that’s [“data”])

      4) Node completes any other necessary startup and publishes itself in live_nodes.

      ...

      1) Roles will be checked in publicly published configuration (i.e. roles API, zk), and a watch can be set to detect any change , if required.

      2) Roles will not be checked by loading config from disk. (ZK ONLY source of truth)

      ...

      • Use autoscaling to stop data (replicas) from being placed on nodes. Autoscaling placement rules may be helpful in avoiding replicas getting placed in a certain node. But, that framework itself has been re-written from Solr 8x to 9x, hence we don’t have a recommendation for users for a consistent way to achieve this. Also, 9x autoscaling framework doesn't support placement plugin chaining, and hence placement plugins shouldn't be used for a first class support of node roles.does not mean other nodes can discover who is performing what functionality or tell a node to start with some feature enabled/disabled
        
      • OVERSEER role is already available today, it indicates "preferred" overseer.

      ...