@SowmyaP
I am not clear on what you are trying to accomplish by specific order of restarts, starts and stops. Can you provide some details around the use case you are trying to implement and why?
In a NiFi cluster the cluster roles "Primary" node and "Cluster Coordinator" node are elected by Zookeeper. Other nodes on the cluster have no specific assigned role. Which node is assigned to these roles can change at anytime, so I am not clear on the importance of specific restart order. If you have designed dataflows around a requirement that a specific node is always the "Primary" elected node, that can't be guaranteed.
In your first "Restart" scenario, assuming that what you mean by "secondary nodes" is any node that is not elected the "Primary" role, each secondary node will restart and rejoin the cluster. If one of those secondary nodes was elected the "Cluster Coordinator" role, that role will switch to another node still running in the cluster. The node elected the "primary" role should retain that role; however, when you then restart the "Primary" node, the "Primary" role will be elected to one of the other nodes in the cluster. When the previous elected "Primary" node rejoins cluster, it will NOT reassume the "Primary" node role.
In your second "start" scenario, assuming all nodes are currently stopped, you can start just the node you want to be elected the "primary" role and wait for that node to completely start and get elected with both the "primary" and "cluster coordinator" roles. Essentially if you access the cluster UI at this point it would show 1 of 1 connected nodes. Then you can start your secondary nodes and they will join the already established cluster.
Third "Stop" scenario, it really does not matter which node you stop first. They get their roles assigned by Zookeeper.
If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.
Thank you,
Matt
