anchor.diff:  require:
   
   * One <<modules-discovery-quorums,elected master node>> node
  +* At least one node for each <<modules-node,role>>.
   * At least one copy of every <<scalability,shard>>.
   
  -We also recommend adding a new node to the cluster for each
  -<<modules-node,role>>.
  -
  -A resilient cluster requires redundancy for every required cluster component,
  -except the elected master node. For resilient clusters, we recommend:
  -
  -* One elected master node
  +A resilient cluster requires redundancy for every required cluster component.
  +This means a resilient cluster must have:
  +
   * At least three master-eligible nodes
   * At least two nodes of each role
   * At least two copies of each shard (one primary and one or more replicas)
  
positive.code: them fails then the remaining two still form a majority and can hold a
  successful election.
  
  Similarly, node redundancy makes it likely that if a node for a particular role
  fails, another node can take on its responsibilities.
  
  Finally, a resilient cluster should have at least two copies of each shard. If
  one copy fails then there is another good copy to take over. {es} automatically
  rebuilds any failed shard copies on the remaining nodes in order to restore the
  cluster to full health after a failure.
  
  Depending on your needs and budget, an {es} cluster can consist of a single
  node, hundreds of nodes, or any number in between. When designing a smaller
  
negative.code: - There are at least two data nodes. 
  - Every index has at least one replica of each shard, in addition to the 
    primary.
  - The cluster has at least three master-eligible nodes, as long as at least two
    of these nodes are not voting-only master-eligible nodes.
  - Clients are configured to send their requests to more than one node or are
    configured to use a load balancer that balances the requests across an
    appropriate set of nodes. The {ess-trial}[Elastic Cloud] service provides such
  