主节点是集群中唯一一个能够更改集群状态的节点。 主节点每一次会处理一批集群状态更新，计算所需的更改，并将更新的集群状态发布到集群中的所有其他节点。 每个节点返回一个已确认，但尚未应用新接收的状态的响应。 一旦主节点从足够多的符合主节点条件的节点收集到确认，新的集群状态就被称为committed(已提交)了，并且主节点会广播另一条消息，指示各节点要去应用现在提交的状态。 每个节点接收此消息，应用更新的状态，然后向主节点发送第二个确认。

主节点允许将每个集群状态更新完全发布到所有节点的时间是有限制的。 它是由 cluster.publish.timeout 设置定义的，默认值为 30s，从发布开始时开始计算。 如果在提交新集群状态之前到达此时间，则拒绝集群状态更改，并且主节点认为自己已失败。 它会停下来，并开始尝试去选举一个新的主节点。

如果新的集群状态是在 cluster.publish.timeout 逝去之前提交的，主节点认为变更操作已经成功。 它等待超时，或者直到它收到确认集群中的每个节点已经应用了更新的状态，然后开始处理和发布下一个集群状态更新。 如果还没有收到一些确认(即: 一些节点尚未确认它们已经应用了当前的更新)，则这些节点被认为是滞后的(lagging)，因为它们的集群状态已经落后于主节点的最新状态。 主节点会等待滞后的节点在一段时间内赶上，这个时间设置为 cluster.follower_lag.timeout，默认值为 90s。 如果节点在此时间内仍未成功应用集群状态更新，则该节点被视为已失败，并已从集群中删除。

集群状态更新通常作为与前一个集群状态的差异发布，这减少了发布集群状态更新所需的时间和网络带宽。 例如，当仅更新集群状态中索引的一个子集的 映射(mapping) 时，只要这些节点具有以前的集群状态，则只需将这些索引的更新发布到集群中的节点。 如果某个节点缺少前一个集群状态，例如，当其重新加入一个集群时，主节点将向该节点发布完整的集群状态，以便它能够接收以后的差异更新。