You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<ahref="/doc/{{version.etcdVersionURL}}/faq#cap-theorem-in-etcd" class="faq-list">CAP theorem in etcd?</a>
27
+
<br>
26
28
</div>
27
29
<divclass="block block-copy half">
30
+
<divclass="faq-list-title">Membership</div>
28
31
<ahref="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq-list">Always remove first when replacing member?</a>
32
+
<br>
33
+
<ahref="/doc/{{version.etcdVersionURL}}/faq#why-so-strict-about-membership-change" class="faq-list">Why so strict about membershp change?</a>
34
+
<br>
29
35
</div>
30
36
</div>
31
37
32
38
<br>
33
39
<hr>
34
40
<br>
35
41
36
-
<h2><ahref="/doc/{{version.etcdVersionURL}}/faq#cap-theorem-in-etcd" class="faq-title">CAP theorem in etcd?</a></h2>
37
42
<divid="cap-theorem-in-etcd"></div>
43
+
<h2><ahref="/doc/{{version.etcdVersionURL}}/faq#cap-theorem-in-etcd" class="faq-title">CAP theorem in etcd?</a></h2>
38
44
<p>
39
45
CAP often represents <i>Consistency</i>, <i>Availability</i>, <i>Partition tolerance</i>: you can only pick 2 out of 3. Since network partition is not avoidable, you are left with either consitency or availability when partition happens. That
40
46
is, systems with A and P are more tolerant of network faults, but possible to serve stale data. etcd chooses C and P to achieve linearizability with strong consistency.
41
47
</p>
42
48
<br>
43
49
44
-
<h2><ahref="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq-title">Always remove first when replacing member?</a></h2>
45
50
<divid="remove-member-first"></div>
51
+
<h2><ahref="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq-title">Always remove first when replacing member?</a></h2>
46
52
<p>
47
53
When replacing an etcd node, we recommend to remove the member first and then add its replacement. etcd employs distributed consensus based on a quorum model; (n+1)/2 members, a majority, must agree on a proposal before it can be committed to the cluster.
48
54
These proposals include key-value updates and membership changes. This model totally avoids any possibility of split brain inconsistency. The downside is permanent quorum loss is catastrophic.
<h2><ahref="/doc/{{version.etcdVersionURL}}/faq#why-so-strict-about-membership-change" class="faq-title">Why so strict about membershp change?</a></h2>
82
+
<p>
83
+
Abandoning quorum is really risky (especially when the cluster is already in a bad way). We're aware that losing quorum is painful, but disabling quorum on membership could lead to full fledged cluster inconsistency and that would be even worse in many
84
+
applications ("disk geometry corruption" being a candidate for most terrifying). It's too dangerous to be a legitimate fix, sorry. Permitting a member add when the cluster is unhealthy is clearly broken and the fix for that, which is safe,
Copy file name to clipboardExpand all lines: frontend/app/doc/tip/why.component.html
+4-4
Original file line number
Diff line number
Diff line change
@@ -22,8 +22,8 @@ <h3 md-subheader>More</h3>
22
22
23
23
<sectionclass="features">
24
24
<divclass="inner">
25
-
<h2><ahref="/doc/{{version.etcdVersionURL}}/why#what-is-etcd">What is etcd</a></h2>
26
25
<divid="what-is-etcd"></div>
26
+
<h2><ahref="/doc/{{version.etcdVersionURL}}/why#what-is-etcd">What is etcd</a></h2>
27
27
<p>
28
28
etcd is distributed reliable key-value store for the most critical data of a distributed system. It is distributed by replicating data to multiple machines, therefore highly available against single point of failures. Using the Raft<sup>[1]</sup> consensus algorithms, etcd gracefully handles network partitions and machine failures, even leader failures.
Application running on <ahref="https://coreos.com/why/" target="_blank" class="normal-link">CoreOS</a> gets automatic, no-downtime Linux kernel updates. CoreOS uses
66
66
<ahref="https://github.com/coreos/locksmith" target="_blank" class="normal-link">locksmith</a> to coordinate those updates. locksmith stores semephore values in etcd. And ensures that only subset of cluster are rebooting at any given
<ahref="http://kubernetes.io/docs/whatisk8s/" target="_blank" class="normal-link">Kubernetes</a> needs configuration storage for service discovery and cluster management. Kubernetes API server writes such persistent cluster states
75
75
in etcd. And uses etcd watch API to get notified whenever changes happen. Consistency is the key to ensure that services correctly schedule and operatate.
76
76
</p>
77
77
78
78
<br>
79
-
<h2><ahref="/doc/{{version.etcdVersionURL}}/why#when-not-to-use">When Not to Use etcd</a></h2>
80
79
<divid="when-not-to-use"></div>
80
+
<h2><ahref="/doc/{{version.etcdVersionURL}}/why#when-not-to-use">When Not to Use etcd</a></h2>
81
81
<p>
82
82
etcd is designed for storing small chunks of data: configuration file, JSON, YAML, etc. etcd limits the size of one request in 1.5MB (see <ahref="https://github.com/coreos/etcd/blob/master/etcdserver/v3_server.go#L34-L38" target="_blank"
83
83
class="code-link">maxRequestBytes</a>). And default storage size limit is 2GB (see <ahref="https://github.com/coreos/etcd/blob/master/mvcc/backend/backend.go#L46-L53" target="_blank" class="code-link">DefaultQuotaBytes</a>). These
0 commit comments