Voting vs Non Voting Servers

• Voting servers participate in leader election and are counted toward the Raft quorum.
• Non-voting servers receive replicated state but do not affect quorum size or election outcomes.
• Adding non-voting members lets you scale read capacity and distribute replicas (for example, zone- or region-local read replicas) without increasing the number of voters and changing fault-tolerance/election dynamics.

​

How non-voting members work

• They do not count toward the Raft quorum.
• They cannot be elected leader.
• They do not improve the fault tolerance of elections (adding a non-voter does not increase the number of failures a cluster can tolerate for leader election).
• The cluster’s peer listing will include non-voters and mark them as such, so you can verify their role from the peers output.

​

Configure a non-voting member

# agent.hcl
# Mark this server as a non-voting member
non_voting_member = true

# Typical other server settings
server = true
datacenter = "dc1"
node_name = "server-nonvoter-1"

# Example: start the agent and mark it as non-voting
consul agent -config-file=/etc/consul.d/agent.hcl --non-voting-member

​

What changes when you add a non-voting member

• Replication: the node receives log entries and state like other servers.
• Quorum: it is not counted toward the Raft quorum.
• Leadership: it cannot be elected leader.
• Availability characteristics: cluster availability and election fault tolerance remain determined by the voting set only.

Node            Address         State     Voter
server-1        10.0.0.1        follower  true
server-2        10.0.0.2        leader    true
server-3        10.0.0.3        follower  true
server-4        10.0.1.10       follower  false  # non-voting member

​

Quick comparison

​

When to use non-voting members

• Read scalability: add replicas for read-heavy workloads without expanding the voting set.
• Geographic locality: deploy non-voters in other regions or availability zones to reduce read latency for users in those locations.
• Safety: increase replica count for durability and read throughput without raising the risk of split-brain from an oversized voter set.
• Testing or audit replicas: keep read-only copies that mirror production state but don’t participate in elections.

​

Best practices

• Keep the voting set small and predictable to reduce election latency and complexity.
• Use non-voters for replicas that need only read access or geographical locality.
• Monitor peers output and replication lag for non-voters to ensure they are healthy and up-to-date.
• When changing voter membership, follow your product’s recommended procedures to avoid unsafe membership transitions.

​

Links and references

• Raft: https://raft.github.io/
• Consul agent documentation: https://www.consul.io/docs/commands/agent