publishing.asciidoc 2.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142
  1. [[cluster-state-publishing]]
  2. === Publishing the cluster state
  3. The master node is the only node in a cluster that can make changes to the
  4. cluster state. The master node processes one batch of cluster state updates at
  5. a time, computing the required changes and publishing the updated cluster state
  6. to all the other nodes in the cluster. Each publication starts with the master
  7. broadcasting the updated cluster state to all nodes in the cluster. Each node
  8. responds with an acknowledgement but does not yet apply the newly-received
  9. state. Once the master has collected acknowledgements from enough
  10. master-eligible nodes, the new cluster state is said to be _committed_ and the
  11. master broadcasts another message instructing nodes to apply the now-committed
  12. state. Each node receives this message, applies the updated state, and then
  13. sends a second acknowledgement back to the master.
  14. The master allows a limited amount of time for each cluster state update to be
  15. completely published to all nodes. It is defined by the
  16. `cluster.publish.timeout` setting, which defaults to `30s`, measured from the
  17. time the publication started. If this time is reached before the new cluster
  18. state is committed then the cluster state change is rejected and the master
  19. considers itself to have failed. It stands down and starts trying to elect a
  20. new master.
  21. If the new cluster state is committed before `cluster.publish.timeout` has
  22. elapsed, the master node considers the change to have succeeded. It waits until
  23. the timeout has elapsed or until it has received acknowledgements that each
  24. node in the cluster has applied the updated state, and then starts processing
  25. and publishing the next cluster state update. If some acknowledgements have not
  26. been received (i.e. some nodes have not yet confirmed that they have applied
  27. the current update), these nodes are said to be _lagging_ since their cluster
  28. states have fallen behind the master's latest state. The master waits for the
  29. lagging nodes to catch up for a further time, `cluster.follower_lag.timeout`,
  30. which defaults to `90s`. If a node has still not successfully applied the
  31. cluster state update within this time then it is considered to have failed and
  32. is removed from the cluster.
  33. NOTE: Elasticsearch is a peer to peer based system, in which nodes communicate
  34. with one another directly. The high-throughput APIs (index, delete, search) do
  35. not normally interact with the master node. The responsibility of the master
  36. node is to maintain the global cluster state and reassign shards when nodes join or leave
  37. the cluster. Each time the cluster state is changed, the
  38. new state is published to all nodes in the cluster as described above.