ETCD-节点挂掉会怎样？

最新推荐文章于 2025-10-13 13:53:48 发布
原创 最新推荐文章于 2025-10-13 13:53:48 发布 · 5.9k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#ETCD-节点挂掉会怎样？ #ETCD #集群节点故障

本文通过在三节点的ETCD集群上模拟节点故障，观察并分析其行为。首先，在正常状态下进行基本操作。然后，依次关闭非主节点，发现集群仍能保持部分功能。接着，重启关闭的节点，数据能够同步。但当关闭两个节点时，集群无法正常工作。最后，了解`etcdctl member list`并不显示在线节点。整个过程中，集群会持续尝试恢复所有节点的连接。

今天没别的意思，就是想折腾下ETCD集群如果出现故障后会咋样，随便玩玩。

0.环境是，三台独立的ubuntu机器，搭建的一个三节点的etcd集群。

1.先看下正常状态下的一组操作。

 

 

2.直接干掉一个节点，但是不是主节点。

此时在活着的两台机器上执行 etcdctl member list 都是这个结果

 

然后三台分别执行etcdctl endpoint health，活着的两台是health，死的是unhealth。

最低0.47元/天 解锁文章
PostgreSQL基于ETCD mirror-make流复制搭建跨DC的PG集群高可用方案
07-20
2. **单个PG DB挂掉，且ETCD集群1整体挂掉**： - 数据库仍然能够正常同步并被访问，但可能需要60~90秒的恢复时间。 - 不会丢失数据，但可能会导致数据库写入业务暂停60~90秒。 3. **两个PG DB挂掉，且ETCD集群1...
记etcd节点故障恢复
武小白的博客
04-19 880
故障原因： 电脑断电，导致etcd集群有一个节点启动失败，比对了数据目录，应该是数据不一致导致的。故障现象： etcd服务启动失败，日志中有如下报错： recovering backend from snapshot error: database snapshot file pat...
频繁创建基于Etcd实现的分布式锁会有什么问题？
BUG_zhentan的博客
07-19 1088
今天的主角是CPU压缩组件，它是Go语言开发的。 CPU压缩组件是做什么的？ 业务申请实例时所要的CPU配额往往比实际使用要大很多，使得K8s集群因为CPU分配率饱和无法再创建新的实例，最终导致集群的资源利用率处于非常低的水平。为了让集群的CPU分配率和CPU使用峰值更接近，更进一步提升集群整体的利用率，我们引入了CPU压缩机制。 CPU压缩组件会根据业务晚高峰的实际CPU使用动态调整实例的request，解决业务申请值和实际使用有偏差的问题。 问题描述 突然收到CPU压缩组件所在机器的内存报警。
etcd节点故障修复方案
最新发布
喝醉酒的小白
10-13 500
节点172.x.x.137的etcd服务异常，容器不断重启（Exited状态），导致etcd集群降级运行。
一次k8s本地虚拟机挂起导致的etcd数据文件损坏
qq_38217747的博客
08-20 854
k8s问题排查
K8s 集群高可用master节点ETCD挂掉如何恢复?
山河已无恙
03-17 2777
很常见的集群运维场景，整理分享博文内容为 K8s 集群高可用master节点故障如何恢复的过程理解不足小伙伴帮忙指正不必太纠结于当下，也不必太忧虑未来，当你经历过一些事情的时候，眼前的风景已经和从前不一样了。——村上春树。
k8s部署之etcd 部署 4
weixin_41985495的博客
12-02 316
1 下载etcd安装包 wget https://github.com/coreos/etcd/releases/download/v3.3.7/etcd-v3.3.7-linux-amd64.tar.gz 2 解压安装etcd(3台主机做同样配置) mkdir /var/lib/etcd tar -zxvf etcd-v3.3.7-linux-amd64.tar.gz cp etcd etcd...
k8s集群灾难恢复-原机器不能起来
魂醉的一亩二分地
07-04 2396
环境准备： 192.168.244.11 k8s-company01-master01 192.168.244.12 k8s-company01-master02 192.168.244.13 k8s-company01-master03 192.168.244.15 k8s-company01-lb 192.168.244.14 k8s-company01-worker001 搭建 ...
(k8s)kubernetes集群高可用master节点ETCD全部挂掉如何恢复?
Richardlygo的博客
08-03 672
前提是需要etcd备份文件，如果没有etcd备份，或者其他的备份手段，可能 GG 了这里默认需要使用etcdctl的地方已经安装了该工具。
etcd三节点，其中一个坏掉了的恢复办法
qq_35573061的博客
09-18 963
etcdctl member add 成员名称（主机名） --peer-urls=https://10.8.47.13:2380。五、加入节点 (确保etcd启动参数etcd.env中--initial-cluster-state 为existing)三、从集群中剔除故障节点(确保故障节点etcd服务已停止 systemctl stop etcd)#其中证书实际路径和endpoints,以环境情况为准,查询方式。四、清空故障节点etcd的数据目录。一、配置etcdctl环境变量。六、启动etcd服务。
Etcd 故障节点修复
一名数据库爱好者的专栏
04-07 426
假如出故障节点的 ID=9b3a3d0b383f52f1。
Rancher RKE K8s 集群 etcd 恢复
小单的博客专栏
02-15 1694
因为是基于 Rancher RKE 的集群，所以在这个问题的情况下可以直接通过其默认备份的快照文件进行 etcd 恢复，如果没有做特别配置，etcd 和集群的快照备份文件在。5、最后启动 etcd 容器，查看日志就发现已经正常了，第二个机器同理操作，如果三个 master 都坏了，只要快照文件在，分别操作后启动容器也是没问题的。这个备份文件中包含两个东西：一个是 etcd 的快照 db 文件，一个是该 k8s 集群的集群配置内容，里面包含 kubeconfig、证书等内容。是下载的 etcdctl 文件，
好文推荐 | etcd 问题、调优、监控
朱小厮的博客
05-27 4588
点击上方“朱小厮的博客”，选择“设为星标”后台回复"加群"，加入新技术来源：www.xuyasong.com/?p=1983etcd 原理解析：读《etcd 技术内幕》这...
etcd节点扩/缩容
sre救赎之路
12-14 862
部署新节点配置需要包含集群节点信息。3、修改所有etcd配置并重启。1、新增节点部署etcd。
etcd集群之序
热门推荐
运维Linux和python
02-08 1万+
序言1、为什么要用etcd集群？    集群很好理解，毕竟增加了高可用性了，那为什么要用etcd而不实用zookeeper呢？从运维的角度来看，zk难以维护，而etcd作为后起之秀，则大大减少的运维的成本。2、etcd是什么？    etcd主要用来作为共享的服务配置及服务发现，使用的是raft协议来保证在分布式系统下的数据一致性，而raft算法那么容易理解，对于每个过程也是很好处理的。3、如何使
实战操作-介绍 ETCD 部署两种形式
Kubernetes云计算的专栏
08-10 1814
实战操作-介绍 ETCD 部署两种形式 1. 二进制部署 本文着重介绍集群采用二进制包安装 etcd 。以 etcd-v3.3.15为例。 假设： etcd1：10.16.11.180 etcd2：10.16.11.182 etcd3：10.16.11.181 三台主机从官方下载的发行版二进制包，手动部署，组成kubernetes etcd集群。 1.1 以下三台主机操作 #关闭防火墙 #systemctl stop firewalld #systemctl di.
Kubernetes中etcd节点挂了，修复后重启失败
ljj的学习笔记
04-15 4602
现象： Kubernetes中etcd节点挂了，修复后重启失败 [root@node2 ~]# systemctl start etcd Job for etcd.service failed because the control process exited with error code. See "systemctl status etcd.service" and "journalctl -xe" for details. [root@node2 ~]#systemctl status etcd
异常处理-k8s-ETCD异常
惰立的博客
05-06 976
异常处理-k8s-ETCD异常
k8s etcd 备份和恢复
liudongyang123的博客
04-13 7762
一.环境准备 1.k8s 集群 （我自己的是单master节点的，多master的只需要将备份好的数据在多个master都执行一遍就行了，备份只需要在一个master上备份。） 二.安装etcdctl命令 1.查看etcd的版本，我用的是阿里的etcd docker images 2.下载地址 https://github.com/etcd-io/etcd/releaseshttps://github.com/etcd-io/etcd/releases3.安装etcdctl tar .
主节点服务器挂掉后，备用的主节点会自动是哪台机器？假如我是五台机器的话，
08-14
<think>嗯，用户这次的问题是关于分布式系统中主节点故障后的选举机制，特别关注五节点集群的场景。从引用材料来看，用户似乎正在研究高可用架构，可能是在搭建ZooKeeper或类似分布式协调服务。 用户引用的材料[2][3]直接相关，其中提到ZooKeeper选举的奇数节点原则和具体投票逻辑。这提示我需要重点解释ZooKeeper的ZAB协议选举过程，因为这是最典型的实现方案。不过用户没有限定具体技术栈，所以回答时要注意通用性。 上次对话历史是关于Kafka消费者重复消费的，和当前问题关系不大。但注意到用户两次都涉及分布式系统容错机制，可能是同个系统设计场景的不同环节。用户身份推测是后端架构师或运维工程师，正在搭建高可用集群。 核心问题其实包含两个层面：一是通用选举机制原理，二是五节点集群的具体推演。需要先用基础概念铺垫，再用具体示例说明。特别要注意材料[3]提到的“2.5”这个关键阈值，这是理解过半数的核心。 技术细节上要强调三个要点：1) 故障检测的时效性（session timeout机制）2) 投票阶段的比较规则（优先比较zxid再比较myid）3) 过半数的数学含义（>n/2而非≥n/2）。最后用五节点故障的推演示例把这些点串联起来。 用户可能隐含的疑问是：为什么必须奇数节点？选举期间服务是否完全不可用？这些在回答里通过“过半机制”和“选举期间集群不可用”的说明已经覆盖。但额外补充了“脑裂”的防护机制，因为这是生产环境的关键考量。 最后生成的问题特意包含ZooKeeper具体实现和K8s对比，既延续当前主题又扩展技术视野。如果用户后续追问，还可以深入raft协议差异或者etcd的实现。</think>以下是关于五节点集群中主节点故障时备用主节点选举机制及过程的详细说明： ### 一、选举机制核心原理 1. **过半机制 (Quorum)** 集群需满足：$投票数 > \frac{节点总数}{2}$ 才能选出新主节点[^2][^3] 五节点集群的选举阈值为：$3$票（因 $3 > \frac{5}{2}=2.5$） 2. **选举依据的优先级** 节点按以下顺序比较： ```mermaid graph LR A[最新事务ID(zxid)] --> B[节点ID(myid)] ``` - 优先选择zxid最大的节点（数据最新） - zxid相同时选择myid最大的节点 ### 二、五节点集群选举过程推演 假设集群节点： `myid: A(1), B(2), C(3), D(4), E(5)` 初始主节点为`C(3)`（zxid=100） #### 场景：主节点C故障 1. **阶段1：节点发现故障** - 剩余节点`A,B,D,E`检测到与C的心跳超时 - 集群进入`LOOKING`状态（选举模式） 2. **阶段2：首轮投票** | 节点 | 自投票 | 广播内容 | |------|---------------|----------------------| | A(1) | (zxid=90, myid=1) | "我投A" | | B(2) | (zxid=95, myid=2) | "我投B" | | D(4) | (zxid=98, myid=4) | "我投D" | | E(5) | (zxid=98, myid=5) | "我投E" | 3. **阶段3：投票比较与更新** - **A节点**：收到B(zxid=95), D(zxid=98), E(zxid=98) → 发现D/E的zxid(98) > 自身zxid(90) → 改投D（因myid=4>5? 错误，实际应投zxid最大的节点） **修正逻辑**：zxid相同时比较myid，此处D和E的zxid相同(98)，但E的myid=5>4 → 应改投E - **B节点**：收到D(zxid=98), E(zxid=98) → 改投E（zxid=98 > 95 且 myid=5>4） - **D节点**：收到E(zxid=98, myid=5) → 发现E的zxid与己相同但myid更大 → 改投E - **E节点**：维持自投票 4. **阶段4：达成共识** | 节点 | 最终投票 | 结果统计 | |------|----------|----------| | A | E(5) | E得4票 | | B | E(5) | (>3票) | | D | E(5) | 选举成功 | | E | E(5) | | **结论**：E(5)以4票当选新主节点[^3] ### 三、关键设计保障 1. **脑裂防护** 任何分支必须满足$存活节点数 > \frac{总节点数}{2}$才能选举 ```mermaid graph LR 故障后集群-- 分区1：A,B -->|2节点 < 2.5| 不可用 故障后集群-- 分区2：D,E -->|2节点 < 2.5| 不可用 故障后集群-- 完整组：A,B,D,E -->|4节点 > 2.5| 可选举 ``` 2. **数据一致性优先** - 新主节点自动继承旧主的最大zxid - 从节点通过`ZXID追新`机制同步数据[^1] ### 四、生产环境建议 1. **节点部署** - 最小集群数：$3$节点（容忍1节点故障） - 推荐集群数：$5$节点（容忍2节点故障） 2. **参数优化** ```properties # ZooKeeper配置示例 tickTime=2000 initLimit=10 # 初始化连接超时（10*tickTime） syncLimit=5 # 心跳超时阈值 ``` 3. **故障恢复流程** ```mermaid sequenceDiagram 运维人员->>故障节点： 修复并重启 故障节点->>集群： 发送FOLLOWER状态请求 主节点-->>故障节点： 同步最新数据 故障节点->>集群： 恢复为FOLLOWER ``` > **关键结论**：在五节点集群中，**数据最新(zxid最大)且节点ID最高**的存活节点将成为新主节点。选举过程通常可在$200ms-2s$内完成（取决于`tickTime`配置）[^3]。 --- ### 相关问题 1. ZooKeeper的`ZXID`具体由哪些部分组成？如何保证全局唯一递增？ 2. 在同时存在多个节点故障的场景下，选举算法如何避免死锁？ 3. Kubernetes控制平面（如etcd）的选举机制与ZooKeeper有何本质区别？ 4. 如何监控ZooKeeper选举过程的性能指标？ 5. 为什么偶数节点集群（如4节点）在实际生产中不被推荐？[^2]
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值