@yichengq yichengq released this Sep 10, 2015 · 8933 commits to master since this release

Assets 10

Zero-Downtime Rolling Upgrade from 2.1

Upgrading from etcd 2.1 to etcd 2.2 is a zero-downtime rolling upgrade. The basic approach is that you can upgrade a cluster running etcd 2.1 one-by one to etcd 2.2. For more details, please read the upgrade documentation. If you are running your cluster under etcd 0.4.x, please follow the snapshot migration documentation to upgrade your cluster.
Also, with this release, etcd 2.2 is now the current stable etcd release; as such, all bug fixes will go into new etcd 2.2.x releases and won't be backported to etcd 2.1.x.

Major Changes

[GH 3083] New etcd client

Today we added a new Go etcd client binding to replace the old go-etcd client. The new client provides a clean set of APIs and improves the functionality around request cancellation and error reporting. We encourage you to try it out for new projects and provide feedback on the API via the etcd-dev mailing list. In this release etcdctl also uses this new client, which will improve its reliability.

[GH 3248] Experimental v3 API and new storage demo

We recently proposed a new version of the etcd API that is focused on providing improved features to the key/value store including: range reads, multi-key transactions, binary keys/values, and a longer, more reliable key change history.

This new API also provides an efficient, reliable and scalable way to access the new disk storage backend. The new disk storage backend allows etcd to do incremental snapshots and decreases the memory pressure of large datasets while retaining hot data in memory for fast access. The new storage backend combined with the v3 API will provide even better performance and stability than today’s in-memory store that supports the v2 API.

etcd 2.2 supports a subset of the v3 API for testing and demo purposes. Note that this early preview is a non-clustered version and should not be used in production. You can enable it by setting --experimental-v3demo flag, then build and use the etcdctlv3 tool in the etcd repo to interact with it.

We plan to support an experimental clustered version of v3 API in the next etcd minor release, etcd v2.3.0, currently targeted for release at the end of October.

[GH 3210 GH 3197] Active cluster health checking

In previous releases of etcd, the leader of the cluster was solely responsible for monitoring the health of other members. With this new release, all members of an etcd cluster now regularly check for connectivity and timing differences to other members to ensure cluster-wide health. To ease debugging potential issues etcd now report members that are observed as unhealthy every 30 seconds in the logs. This new feature also helps users explore and understand the stability of their cluster - for example, by exposing clock synchronization issues that might cause incorrect TTL expiration or issue caused by partial network partitions between members.

etcdctl supports a new flag --forever for the cluster-health subcommand. With that flag set, etcdctl will monitor cluster health continuously. You can now run etcdctl cluster-health --forever and it will print out the cluster health information every 10 seconds.

Improved documentation

Based on feedback from the community, we've made a number of improvements to the readability and understandability of our documentation. Moreover, we added two key new documents:

[GH 3275] v2 API change

The newly created unique key is padded with 0s. We now can sort the created unique keys in lexicographic order.

Default GOMAXPROCS changes with Go 1.5

Since Go 1.5, by default Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1. When compiled with Go 1.5, etcd follows the default behavior described above. The released binaries are compiled with Go 1.5. The number of cores used is printed out on start.

[GH 3413] Support Dedicated WAL Directory

etcd 2.2 supports using a dedicated disk to store wal files, which could improve the throughput and stabilize the cluster. It is highly recommended to dedicate a wal disk and set --wal-dir to point to a directory on that device for a production cluster deployment.

[GH 3390] Introduce flag --endpoint in etcdctl

We recommend to use flag --endpoint to specify the etcd cluster endpoints in etcdctl instead of flag --peers. Though two flags perform the same, name --endpoint is clear and straightforward.

Getting Started


To get started on OSX run the following in a terminal:

curl -L  https://github.com/coreos/etcd/releases/download/v2.2.0/etcd-v2.2.0-darwin-amd64.zip -o etcd-v2.2.0-darwin-amd64.zip
unzip etcd-v2.2.0-darwin-amd64.zip
cd etcd-v2.2.0-darwin-amd64

Open another terminal:

./etcdctl set mykey "this is awesome"
./etcdctl get mykey


To get started on Linux run the following in a terminal:

curl -L  https://github.com/coreos/etcd/releases/download/v2.2.0/etcd-v2.2.0-linux-amd64.tar.gz -o etcd-v2.2.0-linux-amd64.tar.gz
tar xzvf etcd-v2.2.0-linux-amd64.tar.gz
cd etcd-v2.2.0-linux-amd64

Open another terminal:

./etcdctl set mykey "this is awesome"
./etcdctl get mykey


To get started with Docker on Linux run the following in a terminal:

docker run --name etcd quay.io/coreos/etcd:v2.2.0
docker exec etcd /etcdctl set foo bar

For advanced usage, please check our docker guide.


To get started with rkt on Linux run the following in a terminal:

# for more info about rkt command line, see related doc at https://github.com/coreos/rkt/blob/master/Documentation/commands.md#rkt-run
rkt run --volume data-dir,kind=host,source=/tmp --mds-register=false coreos.com/etcd:v2.2.0