Hitoshi Mitake 6974fc63ed etcdserver: avoid deadlock caused by adding members with wrong peer URLs
Current membership changing functionality of etcd seems to have a
problem which can cause deadlock.

How to produce:
 1. construct N node cluster
 2. add N new nodes with etcdctl member add, without starting the new members

What happens:
After finishing add N nodes, a total number of the cluster becomes 2 *
N and a quorum number of the cluster becomes N + 1. It means
membership change requires at least N + 1 nodes because Raft treats
membership information in its log like other ordinal log append
requests.

Assume the peer URLs of the added nodes are wrong because of miss
operation or bugs in wrapping program which launch etcd. In such a
case, both of adding and removing members are impossible because the
quorum isn't preserved. Of course ordinal requests cannot be
served. The cluster would seem to be deadlock.

Of course, the best practice of adding new nodes is adding one node
and let the node start one by one. However, the effect of this problem
is so serious. I think preventing the problem forcibly would be
valuable.

Solution:
This patch lets etcd forbid adding a new node if the operation changes
quorum and the number of changed quorum is larger than a number of
running nodes. If etcd is launched with a newly added option
-strict-reconfig-check, the checking logic is activated. If the option
isn't passed, default behavior of reconfig is kept.

Fixes https://github.com/coreos/etcd/issues/3477
2015-09-13 09:31:53 +09:00
2015-09-05 16:08:15 -07:00
2015-09-04 04:51:44 +00:00
2014-12-18 14:59:06 -08:00
2015-09-11 10:22:29 +10:00
2015-09-09 09:50:41 -07:00
2015-09-03 15:32:25 -07:00
2015-09-04 04:51:44 +00:00
2015-09-10 10:03:07 -07:00
2015-09-11 10:22:29 +10:00
2014-11-18 15:01:57 -08:00
2015-08-20 11:39:41 -07:00
2015-09-02 13:28:55 +08:00
2014-10-27 16:43:27 -07:00
2014-01-19 12:25:11 -08:00
2015-03-20 10:51:42 -07:00
2014-09-07 19:45:34 -07:00
2014-01-19 12:25:11 -08:00
2015-08-18 09:42:13 -07:00
2015-09-10 12:24:48 -07:00
2015-09-04 10:52:14 -07:00

etcd

Build Status Docker Repository on Quay.io

Note: master branch may be in unstable or even broken state during development. Please use releases instead of master branch to get stable binaries.

etcd Logo

etcd is a distributed, consistent key-value store for shared configuration and service discovery, with a focus on being:

  • Simple: curl'able user facing API (HTTP+JSON)
  • Secure: optional SSL client cert authentication
  • Fast: benchmarked 1000s of writes/s per instance
  • Reliable: properly distributed using Raft

etcd is written in Go and uses the Raft consensus algorithm to manage a highly-available replicated log.

See etcdctl for a simple command line client. Or feel free to just use curl, as in the examples below.

If you're considering etcd for production use, please see: production-ready.md

Getting Started

Getting etcd

The easiest way to get etcd is to install one of the pre-built binaries from the tagged releases: instructions are available on GitHub.

For those wanting to try the very latest version, you can build the latest version of etcd from the master branch. All development occurs on master, including new features and bug fixes. Bug fixes are first targeted at master and subsequently ported to release branches, as described in the branch management guide.

Running etcd

First start a single-member cluster of etcd:

./bin/etcd

This will bring up etcd listening on port 2379 for client communication and on port 2380 for server-to-server communication.

Next, let's set a single key, and then retrieve it:

curl -L http://127.0.0.1:2379/v2/keys/mykey -XPUT -d value="this is awesome"
curl -L http://127.0.0.1:2379/v2/keys/mykey

You have successfully started an etcd and written a key to the store.

Running local etcd cluster

First install goreman, which manages Procfile-based applications.

Our Procfile script will set up a local example cluster. You can start it with:

goreman start

This will bring up 3 etcd members infra1, infra2 and infra3 and etcd proxy proxy, which runs locally and composes a cluster.

You can write a key to the cluster and retrieve the value back from any member or proxy.

Next Steps

Now it's time to dig into the full etcd API and other guides.

Contact

Contributing

See CONTRIBUTING for details on submitting patches and the contribution workflow.

Reporting bugs

See reporting bugs for details about reporting any issue you may encounter..

Project Details

Versioning

Service Versioning

etcd uses semantic versioning New minor versions may add additional features to the API.

You can get the version of etcd by issuing a request to /version:

curl -L http://127.0.0.1:2379/version

API Versioning

The v2 API responses should not change after the 2.0.0 release but new features will be added over time.

32-bit systems

etcd has known issues on 32-bit systems due to a bug in the Go runtime. See #358 for more information.

License

etcd is under the Apache 2.0 license. See the LICENSE file for details.

Description
Distributed reliable key-value store for the most critical data of a distributed system
Readme
Languages
Go 96.5%
Shell 2%
Jsonnet 1.1%
Makefile 0.3%
Procfile 0.1%