- 博客(1857)
- 收藏
- 关注
RSS订阅原创 JDBC 连接池
本文介绍了数据库连接池中max-active参数的作用及常见配置参数含义。max-active用于限制连接池中最大活动连接数，防止资源过度占用导致性能下降。文章详细解析了连接池配置参数如name、auth、driverClassName等的功能，并对比了maxIdle、minIdle、initialSize等性能调优参数。同时阐述了连接池的工作原理，包括连接的获取、归还机制，以及如何通过HikariCP等实现来管理JDBC连接。最后指出合理配置连接池参数对系统性能优化的重要性，强调连接池在减少连接创建开销、
2026-01-08 17:19:41
1704
原创 Zookeeper 介绍
本文介绍了Apache ZooKeeper作为分布式协调服务框架的基本概念和用法，重点演示了其在Dubbo分布式系统中的应用。主要内容包括：ZooKeeper通过ZAB协议保证集群数据一致性，提供选主、分布式锁等功能；详细展示了使用Docker部署ZooKeeper及基本命令行操作；通过示例代码说明Dubbo如何利用ZooKeeper实现服务注册发现，包括服务提供者和消费者的注册流程及数据存储结构。文章还介绍了Dubbo与ZooKeeper的交互过程，展示了服务注册、订阅和动态感知的完整机制。
2026-01-08 15:50:35
1593
原创 RocketMQ 死信队列
摘要：死信队列是RocketMQ中处理无法正常消费消息的特殊队列。当消息达到最大重试次数(默认16次)仍消费失败时，会被自动转移到对应的死信队列。死信队列按消费者组创建，存储该组所有相关topic的失败消息，保留时间与普通消息相同(默认48小时)。建议为死信队列配置专门消费者进行兜底处理，如记录日志或特殊业务操作。通过控制台可对死信消息进行重发操作。死信队列机制确保了异常消息不会丢失，为系统提供了可靠的消息处理保障。
2026-01-07 20:15:55
1202
原创 分布式框架Dubbo详细介绍和使用
摘要：Apache Dubbo是一款高性能Java RPC框架，提供分布式服务治理能力。其核心架构包含服务提供者(Provider)、消费者(Consumer)、注册中心(Registry)和监控中心(Monitor)四大组件，支持多种协议和序列化方式。通过XML配置可快速实现服务注册与发现，示例展示了定义HelloService接口、实现类及Dubbo的XML配置过程，包括服务暴露和引用。Dubbo简化了分布式系统开发，具有负载均衡、容错等特性，适合构建企业级微服务架构。
2026-01-06 15:31:45
1200
原创 Zookeeper原理和Dubbo中的作用
Zookeeper是一个分布式协调服务，用于管理配置信息、命名服务、分布式锁等。它采用ZAB协议保证数据一致性，通过领导者选举和数据同步机制实现集群协调。在Dubbo框架中，Zookeeper作为注册中心，支持服务注册、发现、心跳检测和动态切换功能。配置示例展示了如何通过XML文件集成Zookeeper与Dubbo，实现服务提供者和消费者的通信协调。Zookeeper为分布式系统提供了高可用、负载均衡等关键支持。
2026-01-05 14:33:27
1532
原创 深入理解zookeeper session机制
ZooKeeper的session机制是客户端与服务端建立连接的核心机制。session创建时初始状态为connecting，连接成功后变为connected，通过心跳机制维持存活状态。session可设置超时时间，若超时未交互则自动断开。当session过期时，所有临时节点会被自动删除。心跳机制类似ping操作，客户端定期发送心跳包表明存活状态。实验表明，快速重连时临时节点仍存在，因为未超过session超时时间；而长时间断开或手动关闭session后，临时节点会被清除。这种机制确保了分布式系统的节点状态
2025-12-22 10:14:47
1553
原创 Zookeeper监控指标详解：Prometheus+Granfa实战
摘要：Zookeeper作为分布式系统的核心组件，其稳定性直接影响整个架构。本文针对Zookeeper监控难题，提出完整解决方案：首先解析核心指标（连接数、请求延迟、Leader选举等）及其重要性；然后详细指导如何从零搭建Prometheus+Grafana监控系统，包括配置Exporter、采集指标和数据可视化；最后提供性能优化建议和常见问题排查方法。通过这套方案，开发者可实时掌握Zookeeper健康状态，快速定位故障，预防系统崩溃，确保分布式协调服务稳定运行。
2025-12-18 14:50:48
2104
1
原创 zookeeper 常用命令之zkCli
摘要：本文介绍了ZooKeeper客户端zkCli.sh的基本操作。主要内容包括：1）默认连接localhost:2181；2）节点类型（-s持久节点，-e临时节点）；3）节点操作（创建、查看子节点、获取节点状态）；4）数据修改（dataversion版本控制机制，类似MySQL乐观锁）；5）递归删除路径。重点讲解了通过set命令修改节点数据时dataversion的递增机制及其并发控制原理。
2025-12-16 19:36:10
1729
原创 Zookeeper 分布式应用知识CAP理论知识
任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在 本次会话中就不会再读到比这值更旧的值会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。（只要数据更新之后被用户读取到了，这个用户就不会再读取到旧的值，获取到的数据是单调递增的）（服务一直可用，而且是正常响应时间）（zk其中有节点宕机了，这个时候要重新进行选举，在选举的期间是不能对外进行读写的，其实就是牺牲了可用性）个节点，挂了几个，不影响服务，越多机器越好）
2025-12-07 13:27:41
1863
原创 zookeeper 什么是微服务注册中心？
摘要：注册中心是服务治理的核心组件，基于生产者-消费者模型运作。服务提供者启动时向注册中心注册信息，消费者通过订阅获取服务地址。以Dubbo+Zookeeper为例，提供者将URL写入ZK目录，消费者订阅获取地址并注册自身信息。注册中心通过心跳机制监测服务可用性，超时未响应则删除节点并通知消费者。这种机制实现了服务的动态发现和故障处理，避免了手动修改配置的中断问题。Dubbo+ZK组合是常见的注册中心实现方案，通过目录订阅和心跳机制有效管理服务生命周期。
2025-12-04 10:22:11
1933
原创 Kubernetes 证书以及证书续期、过期处理
Kubernetes集群通过多套CA证书体系实现组件间双向认证，确保通信安全。集群包含三套主要CA证书（K8s自身CA、front-proxy CA和etcd CA），其中根CA证书自签名且有效期长达10年。各组件证书（如apiserver、kubelet等）由CA颁发，有效期较短（通常1年）。不同于常规HTTPS的单向认证，K8s严格要求服务器端和客户端的双向验证，所有组件通信都需经过apiserver这个核心网关。用户账号证书也被集成在配置中，非CA证书同样遵循1年有效期原则。证书过期将导致集群完全不可
2025-11-14 16:33:13
2717
原创 RocketMQ集群核心概念 生产者端的负载均衡
摘要：RocketMQ的负载均衡分为生产者和消费者两部分。生产者通过TopicPublishInfo路由信息选择消息队列，MQFaultStrategy类定义容错策略，提供latencyFaultTolerance机制实现高可用。消费者基于拉模式获取消息，通过AllocateMessageQueueStrategy接口实现多种负载均衡策略，如平均哈希、循环平均、机房优先等。消费组内需保证队列分配均衡，避免单个消费者处理过多队列的情况。当队列与消费者关系变化时会触发rebalance重新分配。
2025-11-05 21:50:13
3022
原创 Kubernetes 在生产环境的调优笔记，建议收藏！
本文基于生产实践，详细剖析了Kubernetes集群从1000节点扩展到5000节点的系统化优化方案。核心内容包括：控制平面扩容与参数调优、etcd集群深度优化、网络架构升级、调度策略精细化等关键场景。通过某互联网公司真实案例，展示了分阶段实施的具体步骤和效果对比，最终实现APIServer响应时间降低85%、Pod调度时间缩短80%、节点资源利用率提升132%等显著优化。文章总结了大规模集群运维的关键经验，并展望了虚拟集群、边缘计算、AI调度等未来发展方向。为面临集群扩展挑战的架构师和运维工程师提供了可落
2025-10-21 09:14:19
4050
原创 RocketMQ 集群核心概念-幂等消息-幂等问题的出现
消费者在拿到消息以后，它已经将消息存在DB里面了，它已经完成它的业务了，正常要返回ack，只剩下最后一步提交offset，但是在提交offset的时候，不巧消费者挂掉了，那么意味着这个offset没有办法被提交。现在由于网络的抖动导致生产者这条消息发送之后没有办法收到broker的ack，那么生产者根据之前的机制的设定还会再次去发送，那么这条消息按照正常的链路来走的话就是被消费者消费两次。或者在消费完一条消息的时候，在提交offset的时候，消费者1挂掉了，然后消费者2继续将这条消息存放到数据库里面。
2025-10-14 20:05:03
3770
原创 Kubernetes 证书监控--x509-certificate-exporter
本文介绍了在Kubernetes集群中部署x509-certificate-exporter监控工具的配置方法。该工具通过监控集群节点上指定的证书文件和kubeconfig文件来获取证书信息。文章详细列出了需要监控的证书文件路径，并提供了从GitHub下载和修改配置文件的步骤，包括调整Chart版本号、镜像仓库地址等关键配置项。同时说明了如何通过Helm命令安装该工具，以及部署后如何检查Pod运行状态。最后还提供了异常处理建议，包括检查日志和解决证书文件权限问题的方法。
2025-09-23 17:53:45
3579
原创 RocketMQ 集群核心概念-消息重试-触发重试的条件
消息消费过程中，消费者会从broker获取消息但不会立即删除。消费者通过提交offset到consumerquenue文件来标记消息消费进度。若消费失败未提交offset，broker会保留消息并触发重试机制。当消费者宕机时，系统会通过rebalance机制将队列重新分配给其他消费者，新消费者会从最后一个已提交的offset位置继续消费。这种机制确保了消息不会因消费异常而丢失，同时支持负载均衡和故障转移。
2025-09-15 10:33:37
3607
原创 RocketMQ 集群核心概念-消息主从复制
生产者producer发送了一个消息过来，然后在master上面这个数据进来了，如果是同步方式的话，那么要等这个消息同步到slave节点上之后，那么这个broker集群才会返回ack给我们的producer。异步也可以得到broker返回的消息，但是发送完消息不需要一直等broker给我返回，这里只需要放一个回调函数，当broker返回确认消息，这个方法就会被调用，在发送完消息就可以做其他事情了。同步的方式：当生产者发送消息，消息同步到了从节点，这个时候才会返回确认消息给producer。
2025-09-10 20:48:11
3573
原创 RocketMQ 消息存储机制-索引文件及页缓存
摘要：RocketMQ采用混合存储结构，将生产者消息写入CommitLog文件，同时构建ConsumeQueue逻辑队列和IndexFile索引文件。IndexFile支持通过key或时间区间查询消息，底层采用hash索引结构。通过页缓存、顺序读写和零拷贝技术优化读写性能。Broker启动时通过abort文件判断上次关闭状态，配置信息存储在json文件中。这种设计保证了消息持久化存储和高效检索，同时支持长轮询消费模式。
2025-09-02 16:28:30
4368
原创 Velero 实现k8s跨集群迁移
K8s集群数据迁移指南 摘要：本文介绍了使用Velero工具实现Kubernetes集群间数据迁移的方法。首先需要在目标端部署干净的K8s集群，然后安装Velero服务端和客户端，配置与原集群相同的MinIO存储地址以获取备份文件。迁移过程包括：1）在目标集群部署Velero并连接源MinIO；2）查看并确认备份数据可用；3）执行还原命令；4）验证资源恢复情况。注意目标集群配置（如节点数、版本）可与源集群不同，但核心数据将保持一致。整个迁移过程实质是备份还原操作的跨集群实现，最终确保数据完整移植到新环境。
2025-09-02 11:20:46
3448
原创 velero 数据备份与恢复时的资源过滤（指定ns/资源/label）
本文介绍了Velero工具中资源过滤的使用方法，包括包含和排除标志的应用。通过include/exclude选项可以按命名空间、资源类型或标签选择性地备份和恢复Kubernetes对象。主要内容涵盖：1）包含功能（--include-）可指定特定资源；2）排除功能（--exclude-）可过滤不需要的资源；3）集群范围资源（--include-cluster-resources）的三种处理方式；4）标签选择器（--selector）实现更细粒度控制；5）特殊标签velero.io/exclude-from-
2025-08-27 15:46:34
3875
原创 RocketMQ 消息存储机制-消息刷盘
消息刷盘分为同步和异步两种方式。同步刷盘确保消息写入磁盘后才返回确认，可靠性高但吞吐量低；异步刷盘先将消息存入内存页缓存后立即返回确认，由后台线程异步写入磁盘，提高了吞吐量但存在数据丢失风险。两种方式在可靠性和性能之间各有侧重。
2025-08-26 20:08:08
2602
原创 RocketMQ 消息存储机制 CommitLog和ConsumerQu
摘要：RocketMQ通过CommitLog文件存储所有消息，采用顺序写入提升性能。为优化消费效率，引入ConsumeQueue作为索引，按Topic/QueueId组织，记录消息在CommitLog中的物理偏移量。CommitLog默认1G大小，写满后创建新文件；ConsumeQueue采用定长设计（20字节/条目），实现快速检索。这种物理存储+逻辑索引的架构既保证了消息持久化，又提升了消费性能，同时支持消费者偏移量管理以实现故障恢复。
2025-08-13 20:11:43
3244
原创 velero 资源备份恢复测试 定期备份
摘要：本文介绍了使用Velero工具进行Kubernetes集群备份和恢复的操作流程。主要内容包括：1）通过velerobackup create命令创建带时间戳的命名空间备份；2）使用velerobackup describe查看备份状态；3）演示删除命名空间后，通过velero restore create从指定备份恢复应用和数据；4）验证恢复后Pod和数据完整性。整个过程展示了Velero在K8s环境中的备份恢复能力，包括元数据备份、持久化数据恢复等功能。
2025-08-13 16:20:40
2812
原创 containerd 配置镜像加速
本文介绍如何配置containerd镜像加速器。首先修改config.toml文件，添加registry插件配置，指定证书目录。然后创建对应的certs.d目录结构，为docker.io、registry.k8s.io等镜像仓库配置hosts.toml文件，添加阿里云、DaoCloud、163等国内镜像源。配置完成后需重启containerd服务。注意ctr命令与crictl命令的差异，以及不同镜像仓库的配置方法。文中提供了docker.io、registry.k8s.io和k8s.gcr.io三种常见镜像
2025-08-13 14:06:46
3944
3
原创 Velero 简介和部署
摘要：Kubernetes集群备份工具Velero支持资源备份和PV数据迁移，与etcd备份形成互补。Velero通过API server进行细粒度备份（如按命名空间、标签等），支持周期性备份，而etcd直接备份整个数据库。部署Velero需安装客户端和服务端（控制器），配合对象存储（如Minio）使用，需配置访问凭证。Velero备份流程包括创建Backup对象、资源收集和存储上传，恢复时通过Restore控制器完成。相比etcd，Velero提供了更灵活的备份策略和迁移能力，适合生产环境集群数据的管理和
2025-08-05 16:47:43
3769
2
原创 如何使用 Nginx Ingress 实现金丝雀发布
本文详细介绍了如何使用Nginx Ingress实现金丝雀发布，包括两种主要场景：1）基于Header/Cookie的定向灰度发布，可将新版本面向特定用户群体；2）基于权重的流量比例切分（0-100%）。文章提供了完整的YAML配置示例，涵盖v1/v2版本部署、常规Ingress创建以及三种Canary策略实现（Header匹配、Cookie识别和权重分配）。同时指出了Nginx Ingress在Canary发布中的局限性，如仅支持两个版本共存、必须配置域名等。该方案适合使用Nginx Ingress且发布
2025-08-01 13:58:26
3478
原创 如何根据不同业务场景调节 HPA 扩缩容灵敏度
Kubernetes HPA自动扩缩容灵敏度控制指南 Kubernetes 1.18对HorizontalPodAutoscaler(HPA)进行了重要更新，新增了behavior字段用于控制扩缩容灵敏度。该功能允许用户根据业务需求定制化扩缩容策略：关键业务可配置快速扩容（立即新增9倍副本）和缓慢缩容（每10分钟缩1个Pod）；非关键业务可设置缓慢扩容（每次新增1个Pod）；还可禁止自动缩容或延长扩缩容时间窗口（最长10分钟）以避免误操作。这些特性通过scaleUp/scaleDown策略实现，使HPA能更
2025-07-23 15:16:04
3303
原创 Kubernetes 探针原理、效果以及配置建议
Kubernetes容器探针主要包括启动探针(StartupProbe)、存活探针(LivenessProbe)和就绪探针(ReadinessProbe)。启动探针用于检测容器初始化完成，存活探针判断容器是否正常运行，就绪探针确认容器是否准备好接收流量。探针支持HTTP请求、TCP连接和执行命令三种检测方式，并可通过参数调整探测行为。配置建议包括：慢启动应用应优先配置启动探针，调整合适的探测时间间隔，存活探针失败阈值应大于就绪探针等。探针失败时，存活探针会导致容器重启，就绪探针则从服务中移除实例。
2025-07-21 14:56:44
3627
原创 K8s 集群CoreDNS监控告警最佳实践
CoreDNS作为Kubernetes集群的核心DNS服务，其性能监控至关重要。关键监控指标包括：请求速率（按协议、记录类型分组）、响应速率（按状态码）、UDP/TCP请求/响应数据包大小（P50/P90/P99）、响应时延（P99阈值建议设为1s）以及缓存指标（记录数、命中/丢失率）。这些指标通过Prometheus采集，使用PromQL进行查询和告警配置。重点需关注P99响应时延、请求速率和缓存命中率，其中响应时延初始告警阈值可设为1秒（基于DNS解析超时时间2s），后续根据实际数据优化。
2025-07-21 11:18:50
2904
原创 Kubernetes NodeLocal DNSCache 简介
DNSConfig动态注入控制器，基于Admission Webhook机制拦截Pod创建的请求，自动注入使用DNS缓存的Pod DNSConfig配置；DNS缓存代理，在每个集群节点上创建一个虚拟网络接口（默认监听IP 169.254.20.10），配合Pod的DNSConfig和节点上的网络配置，Pod内产生的DNS请求会被该服务所代理。工作原理图如下图所示：1、已注入DNS本地缓存的Pod，默认会通过NodeLocal DNSCache的服务地址（169.254.20.10）解析域名;
2025-06-27 10:59:01
3552
转载 记一次 k8s dns解析异常故障分析
事情是这样的，有天有个客户找到我，说他在k8s集群里面部署了一套KubeFlow，pod状态都是正常的，但是登录的时候界面报了一个500错误，并给我发了下面这张截图，我当时也不知道KubeFlow是啥，但是我注意到了截图上面显示的url地址，“oauth2/callback”看名称是一个认证回调相关的地址，初步怀疑是调用这个oauth2接口异常了所以报错。只能去提供这个接口的pod里找日志了，以下是客户部署的KubeFlow的pod，注意到最底下的2个pod，就是提供认证接口的pod。
2025-06-25 15:48:41
2553
原创 CoreDNS 配置优化实践
如果在云容器引擎集群中部署的应用容器使用了Alpine作为基础镜像，可能会因为下述musl libc特性导致无法正常解析域名，此时建议尝试更换基础镜像，如Debian、CentOS等。当集群的kube-proxy负载均衡模式为IPVS时，缩容或重启CoreDNS可能会遇到DNS概率性解析超时的问题。该问题由社区Linux内核缺陷导致，具体信息请查看社区。。。CoreDNS启动时会默认获取实例所在节点中的DNS配置而且在CoreDNS重启之前不会再重新加载该节点上的resolve.conf配置。
2025-06-24 11:02:30
3266
原创 Kubernetes CoreDNS策略配置和域名解析说明
本文介绍了在Kubernetes集群中配置Pod DNS策略的方法，主要包含四种场景：1) 使用ClusterFirst策略默认采用集群CoreDNS解析域名；2) 通过None策略自定义Pod的DNS配置；3) 使用Default策略继承节点ECS的DNS配置；4) 在HostNetwork模式下采用ClusterFirstWithHostNet策略访问集群服务。文章详细说明了每种策略的适用场景、示例配置和关键参数，并提供了集群DNS服务的基本查询方法，帮助用户根据实际需求选择合适的DNS解析方案。
2025-06-09 09:56:31
3097
原创 Kubernetes CoreDNS 概述
Kubernetes集群中的DNS解析机制主要依靠CoreDNS和NodeLocalDNSCache组件实现。CoreDNS负责解析集群内服务域名（格式为<servicename>.<namespace>.svc.<ClusterDomain>）和外部域名，作为集群默认DNS服务器运行。NodeLocalDNSCache则在每个节点部署DNS缓存，减轻CoreDNS负载并提升解析效率。集群DNS配置包含三个层面：全局的ClusterDomain设置（默认cluster.l
2025-06-06 10:40:59
2482
原创 etcd 性能 FIO测试
etcd作为一个分布式键值存储系统，其性能主要由延迟和吞吐量两个因素决定。延迟指完成操作所需时间，而吞吐量则是在特定时间内完成的操作数量。在并发客户端请求下，etcd的平均延迟会随吞吐量增加而增加。在标准云环境中，三成员etcd集群在轻负载下可实现低于1毫秒的请求完成时间，重负载下每秒可处理超过30000个请求。etcd使用Raft算法确保数据一致性和复制，其性能受网络和磁盘IO延迟限制。为提高吞吐量，etcd采用批量处理策略。此外，etcd的性能还受到MVCC存储引擎、快照、压缩和gRPC系统的影响。通过
2025-05-23 09:50:47
2532
原创 云原生|kubernetes|kubernetes的etcd集群备份策略
总结：etcd恢复还是比较快的，脚本做了一些工作，比如，停服务，因此，恢复完要先启动etcd，然后在其它节点启动etcd，最后启动kube-apiserver服务，顺序不要搞错了哦。可将备份脚本放入计划任务，实现自动备份哈，这里我就不演示啦，然后恢复的时候根据需要恢复任意天的etcd。再次强调，集群恢复是所有节点都恢复，不能只恢复一个节点，那样会劈叉的，根据每个节点的etcd配置文件修改脚本。
2025-05-13 15:04:03
3890
原创 ETCD 集群的常见问题处理(2)
本文介绍了ETCD集群在日常运维中常见问题的处理方法。ETCD是一个高可用的分布式Key/Value存储系统，使用Raft算法保持集群一致性。文章详细描述了三种常见问题的解决步骤：1）单个节点宕机的恢复，包括查看状态、摘除异常节点、重新部署和加入集群；2）超过半数节点宕机的恢复，涉及备份数据恢复、启动服务和检查状态；3）数据库空间超限的恢复，包括备份数据、获取reversion、compact、defrag和删除报警。文章还建议定时备份和压缩数据，并增加集群监控以确保服务稳定运行。
2025-05-12 10:34:09
3482
原创 Etcd 数据存储文件 配置建议和管理
etcd集群在正常服务时，成员分为Leader和Follower两种状态，确保数据强一致性。所有数据从Leader流向Follower，Follower数据必须与Leader一致，否则会被覆盖。Leader处理所有写操作，并需等待超过半数的成员确认写操作成功，而Follower可直接响应读操作。etcd采用预写式日志（WAL）记录所有数据库事务，确保数据持久化。此外，etcd定期生成数据库快照（snapshot），记录某一时间点的数据状态，以减少日志体积并辅助数据恢复。快照与WAL日志结合，可快速同步故障实
2025-05-09 17:20:32
2896
原创 Vue 生命周期详解
vue的生命周期，是vue中比较重要的知识点，在面试中也经常会被问到，所以就打算写一篇关于vue生命周期的文章。世间万物都有自己生命周期⏱，vue也有这一特点，vue的生命周期可以简单分为四个阶段：创建阶段，挂载阶段，运行阶段，销毁阶段。每个 Vue 实例在被创建时都要经过一系列的初始化过程——例如，需要设置数据监听、编译模板、将实例挂载到 DOM 并在数据变化时更新 DOM 等。❝在这个过程中会运行一些叫做生命周期钩子的函数，这给了用户在不同阶段添加自己的代码的机会❞每个阶段都有两个。
2025-05-09 11:19:58
3489
原创 Kubernetes etcd 故障恢复(1)
本文介绍了处理ETCD集群故障的步骤，包括查看集群状态、剔除故障节点、重新添加故障节点以及备份恢复集群的方法。首先，通过etcdctl命令查看集群状态，识别主节点和故障节点。接着，使用member remove命令剔除故障节点，并通过member list验证剔除是否成功。随后，详细说明了重新添加故障节点的步骤，包括清空旧数据、修改配置文件、拷贝证书以及执行member add命令。最后，文章还提供了备份恢复集群的流程，强调停止相关服务、恢复数据后重启服务的操作顺序。通过这些步骤，可以有效维护ETCD集群的
2025-05-09 11:04:05
3642
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人