NOTE: this doc is not finished!
All Responses from etcd API have a response header attached. The response header includes the metadata of the response.
message ResponseHeader {
uint64 cluster_id = 1;
uint64 member_id = 2;
int64 revision = 3;
uint64 raft_term = 4;
}
- Cluster_ID - the ID of the cluster that generates the response
- Member_ID - the ID of the member that generates the response
- Revision - the revision of the key-value store when the response is generated
- Raft_Term - the Raft term of the member when the response is generated
An application may read the Cluster_ID (Member_ID) field to ensure it is communicating with the intended cluster (member).
Applications can use the Revision
to know the latest revision of the key-value store. This is especially useful when applications specify a historical revision to make time travel query
and wishes to know the latest revision at the time of the request.
Applications can use Raft_Term
to detect when the cluster completes a new leader election.
Key-Value API is used to manipulate key-value pairs stored inside etcd. The key-value API is defined as a gRPC service. The Key-Value pair is defined as structured data in protobuf format.
A key-value pair is the smallest unit that the key-value API can manipulate. Each key-value pair has a number of fields:
message KeyValue {
bytes key = 1;
int64 create_revision = 2;
int64 mod_revision = 3;
int64 version = 4;
bytes value = 5;
int64 lease = 6;
}
- Key - key in bytes. An empty key is not allowed.
- Value - value in bytes.
- Version - version is the version of the key. A deletion resets the version to zero and any modification of the key increases its version.
- Create_Revision - revision of the last creation on the key.
- Mod_Revision - revision of the last modification on the key.
- Lease - the ID of the lease attached to the key. If lease is 0, then no lease is attached to the key.