etcd v3集群全成员写入基准测试疑问：如何实现全成员写入？

Great question! Let's break this down clearly since etcd's Raft consensus model enforces that all write operations must go through the leader—so directly writing to every member isn't the default behavior. But if you need to test sending write requests to each member individually (for benchmarking or validating request handling), here's what you need to know and how to do it:

Understand the Default Behavior #

First, a quick recap: Even if you specify multiple endpoints in your benchmark command with --endpoints=${HOST_1},${HOST_2},${HOST_3}, the etcd client will automatically discover the cluster leader and route all write requests to it. Any write requests sent to a follower will be forwarded to the leader by the follower itself. So your original command isn't actually writing to all members—it's just using multiple endpoints for initial client connection, but all writes end up going through the leader.

Ways to Target All Members for Write Requests #

If your goal is to send write traffic directly to each member (to test their ability to handle and forward requests, for example), here are two practical approaches:

1. Loop Through Each Endpoint Individually #

The simplest way is to run your benchmark command multiple times, each time targeting a single member's endpoint. You can automate this with a shell script. For example:

# Define your etcd cluster members
HOSTS=("${HOST_1}" "${HOST_2}" "${HOST_3}")

# Run benchmark for each member
for host in "${HOSTS[@]}"; do
  echo "Running benchmark against $host..."
  etcdctl benchmark write to all members benchmark --endpoints=$host --conns=100 --clients=1000 put --key-size=8 --sequential-keys --total=100000 --val-size=256
done

This way, each benchmark run sends requests directly to one specific member. Keep in mind: when targeting a follower, the member will still forward the write to the leader to maintain Raft consensus—you're just testing the follower's request routing capabilities, not writing directly to its local storage.

2. Avoid Trying to Write Directly to Followers' Storage #

Important note: etcd does not support writing directly to a follower's local storage bypassing the leader. This would violate Raft's consensus rules, leading to data inconsistency, cluster splits, or other unstable states. There's no official way to do this, and it's strongly discouraged for any production or valid testing scenario.

Final Notes #

If your benchmark goal is to measure overall cluster write performance, the original command targeting multiple endpoints is fine—it will leverage the leader for all writes, which is the normal operational flow. If you specifically need to test each member's ability to handle incoming write requests (and forward them), the loop approach is the correct way to go.

内容的提问来源于stack exchange，提问作者foo