Zookeeper --笔记

最新推荐文章于 2025-01-23 00:34:24 发布
原创 最新推荐文章于 2025-01-23 00:34:24 发布 · 235 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入探讨Zookeeper在分布式系统中的核心作用，包括服务注册与发现、数据一致性保证、ZAB协议详解、节点类型及数据变更通知机制。同时，分析了Zookeeper在负载均衡、集群管理、分布式锁和队列中的应用，并对比了多种一致性协议和算法。

分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名
服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

 

Zookeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心(提供发布订阅服务)。 服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。如下图所示，在 Dubbo架构中 Zookeeper 就担任了注册中心这一角色。

 

image.png

zookeeper保证了如下分布式一致性特性：

1.顺序一致性 2.原子性 3.单一视图 4.可靠性 5.实时性

image.png

 

ZAB协议

ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。

ZAB协议的两种模式：崩溃恢复和消息广播

消息广播：leader将请求广播出去，让Leader问问Followers是否同意更新，超过半数同意，就可以进行follower和observe的更新。用图来标示一下。

image.png

队列需要让follower和observe保证顺序性

 

崩溃恢复：

选举算法---第一阶段：宕机重新选举 ；第二阶段：当zookeeper启动需要进行系统的Leader初始化选择。

假设有三台，启动server1，投票给自己，内容为服务器的myid和ZXID,因为初始化ZXID都是0，server1的发出的投票为（1,0），server1投票为1，不能为leader，此时为looking状态，

server2投票为（2,0），广播出去（server1也会，只是当时没有其他服务器），server1收到后和自己比较，先比较ZXID,ZXID大的为Leader，若相同，比较myid，myid大的为Leader。此时server1发现server2更适合，如更新自己的投票信息为（2，0）然后广播出去。server2收到后，和自己一样不更新，且已经超多一般的票数，则server2是Leader，server1是Follower。整个服务器从Looking变成正常状态。

server3启动发现句群没有Looking，直接以Follower的身份加入的集群。

 

四种类型的节点

1.持久节点 2.临时节点 3.持久顺序节点 4.临时顺序节点

可为节点添加一个属性--SEQUENTIAL,加上属性后，在被创建时，zookeeper会给节点追加一个数字。

这个数字有父节点维护的自增数字。

 

数据变更通知 Zookeeper Watcher

 

最好用奇数台构成集群

 

会话 Session

在Zookeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。通过连接，客户端通过心跳与服务器保持连接。

 

Znode

通常我们所说的节点是指组成集群的每台机器。然而，在zookeeper中，节点分两种

第一类：指构成集群的机器，称之为机器节点

第二类：指数据模型中的数据单元，称之为数据节点-ZNode

znode三个数据版本：version(当前的ZNode版本)，cversion(当前ZNode子节点的版本)和aversion（当前ZNode的ACL版本）

 

ACL权限控制机制

zookeeper五种权限，CREATE和DELETE这两种权限都是针对子节点的权限控制

image.png

 

顺序访问

image.png

 

zookeeper集群角色

最典型集群模式： Master/Slave 模式（主备模式）

在 ZooKeeper 中

没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色

image.png

 

image.png

 

ZAB协议

ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。主要依赖 ZAB 协议来实现分布式数据一致性。

两种模式：崩溃恢复和消息广播

 

服务器角色

Leader 1.事务请求的唯一调度和处理者，保证集群事务处理的顺序性 2.集群内部各服务的调度着

Follower：1.处理费非事务请求，转发事务请求给Leader服务器 2参与事务请求Proposal的投票 3.参与leader选举投票

Observer：提升非集群的非事务处理能力，处理客户端的非事务请求，转发事务请求给Leader服务器。不参与任何形式的投票

 

服务器四种状态：LOOKING,FOLLOWING,LEADING,OBSERVING

image.png

zookeeper的数据同步通常为四类

直接差异同步DIFF

先回滚在差异化同步 TRUNC+DIFF

仅回滚同步TRUNC

全量同步 SNAP

 

部署模式：

单机模式，为集群模式，集群模式

集群规则为：2N+1台，N>0,即3台。

 

能支持动态添加吗？

不太好，能添加。两种方式：

全部重启，逐个重启。 3.5版本后支持动态扩容。

 

zookeeper对节点的监听不是永久的。

 

常用命令：ls，get，set，create，delete等

 

ZAB和Pacos算法的联系和区别

 

基于zk的实现：数据存储，数据获取，数据变更

 

负载均衡

 

集群管理：是否有及其退出和加入，选举master

 

zk分布式锁

一致性文件系统，锁分两类：保持独占，控制时序

image.png

zk队列

同步队列：当一个队列的所有成员聚齐，才能使用，否则一直等待。

对待按照FIFO方式入队和出队操作。

image.png

 

一致性协议和算法

拜占庭将军：在不可靠信道上试图通过消息传递的方式达到一致性是不可能得。

2PC

角色：协调者，参与者

事务发起者向协调者发送事务，协调者给所有参与者发送prepare请求，若能执行，就先执行不提交。执行后给协调者返回prepare消息，告诉协调者是否准备好进行提交。

当所有的参与者都返回准备好了的消息，协调者会给参与者发送Commit请求，参与者收到请求后会执行前面事务的提交操作，提交完毕之后给协调者发送提交成功的响应。

 

2pc带来的问题：

单点登陆：协调者宕机，全部不可用。

阻塞问题:即协调者发送prepare请求，参与者受到之后，会进行事务处理，但不及提交，此时会占用资源不释放。如果此时协调者挂了，资源不会释放，这会极大影响性能。

数据不一致：如果第二阶段，协调者只发送了一部分的commit请求就挂了，那么收到的参与者进行事务的提交，而后面没收到的则不会进行事务提交，此时就会进行数据不一致。

 

3PC

CanCommit阶段：协调者向所有的参与者发送CanCommit请求，参与者根据自身返回是否能执行事务，如果返回yes进入预备状态，都在返回NO。

PreCommit阶段：协调者根据参与者返回响应来判断是否可以进行下面的PreCommit操作。如果上面的参与者返回的都是YES，那么协调者将向所有的参与者发送PreCommit预提交请求，参与者收到预提交请求后，会进行事务的执行操作，将Undo和Redo信息写入事务日志。若参与者顺利执行，则给协调者返回成功的响应。

如果在第一阶段协调者收到任何一个no，或者在一定时间内没有收到全部参与者的成功响应，那么就会中断事务，他会向参与者发送中断请求。参与者会立即中断事务，在一定时间没有收到协调者的请求，他也会中断事务。

DoCommit阶段，这个阶段其实和2pc的第二阶段差不多，如果协调者收到所有的参与者在PreCommit阶段的YES响应，协调者将会给所有的参与者发送DoCommit请求，参与者受到DoCommit请求后则会进行事务的提交工作。完成后则会给协调者返回响应。协调者收到所有参与者返回的事务提交成功的响应之后完成事务。若协调者的precommit阶段收到任何一个no或者在一定时间内没有收到参与者的响应，那么就会进行中断请求的的发送，参与者受到中断请回后通过日志进行回滚。并向协调者反馈回滚状态。

 

Paxos算法 --解决数据一致性问题

基于消息传递且具有高度容错特性的一致性算法，其解决的问题是分布式系统中如何就某个值达成一致。

角色：proposer提案者、Acceptor表决者、Learner学习者。Paxos算法和2pc一致，

也有两个阶段：分别为Prepare和accept阶段。

Proposer提案者：负责提出 proposal，每个提案者在提出提案时都会首先获取到一个 具有全局唯一性的、递增的提案编号N，即在整个集群中是唯一的编号 N，然后将该编号赋予其要提出的提案，在第一阶段是只将提案编号发送给所有的表决者。

Acceptor表决者：每个表决者在accept某提案后，会将提案编号N记录在本地，这样在每个表决者中保存的已经在accept的提案中会存在一个编号最大的提案。每个表决者仅会accept编号大于自己本地的提案。在批准提案时表决者会将以前接收的自大编号的提案给提案者。

 

Prepare阶段：

当提案被提出时，如果提案者收到了超过半数的表决者的同一，那就就会给所有的表决者发送真正的提案，这个时候，Proposer就会发送提案内容和编号。

表决者收到提案后，会和自身比较已经批准过得最大提案的编号和该提案编号，如果该提案编号大于已经批准过得提案编号，就accept该提案（执行不提交），随后返回proposer，如果不行不返回，或者返回no。

 

accept阶段

当 Proposer 收到超过半数的 accept ，那么它这个时候会向所有的 acceptor 发送提案的提交请求。需要注意的是，因为上述仅仅是超过半数的 acceptor 批准执行了该提案内容，其他没有批准的并没有执行该提案内容，所以这个时候需要向未批准的 acceptor 发送提案内容和提案编号并让它无条件执行和提交，而对于前面已经批准过该提案的 acceptor 来说 仅仅需要发送该提案的编号 ，让 acceptor 执行提交就行了。

而如果 Proposer 如果没有收到超过半数的 accept 那么它将会将 递增 该 Proposal 的编号，然后 重新进入 Prepare 阶段 。

 

paxos算法死循环问题

image.png

 

 

 

 

 

 

 

zookeeper集群角色
weixin_67050107的博客
04-10 413
zookeeper集群角色
zookeeper学习笔记之-Zookeeper 3.6源码编译
huanglei_hacker的博客
07-25 1054
利用git拉取项目 切分支：release-3.6.1 利用maven下载依赖 直接运行QuorumPeerMain类，编译过程会报错，比如找不到如下包 这些包需要jute生成，进入到zookeeper-jute模块，编译一下： 编译后会生成对应的包，再次运行QuorumPeerMain类，还是报错， 找不到Info接口，这个接口也需要生成，进入到zookeeper-server模块，编译一下： 编译后会生成Info接口，再次运行QuorumPeerMain类，没有报错了，只不过没有启.
zookeeper 简介
xiaojie19871116的博客
06-01 4418
一直对zookeeper的应用和原理比较迷糊，今天看一篇文章，讲得很通透，分享如下：  场景一 有这样一个场景：系统中有大约100w的用户，每个用户平 均有3个邮箱账号，每隔5分钟，每个邮箱账需要收取100封邮件，最多3亿份邮件需要下载到服务器中(不含附件和正文)。用20台机器划分计算的压力，从 多个不同的网路出口进行访问外网，计算的压力得到缓解，那么每台机器的计算压力也不会很大了。
你知道Zookeeper中有哪些角色？
qq_33240556的博客
12-16 1000
Zookeeper是一个分布式协调服务，用于管理共享数据和提供分布式应用程序的协调功能。这些角色共同构成了Zookeeper的架构，它们协同工作以提供分布式应用程序所需的协调和数据管理功能。跟随者（ ） Follower服务器为客户端提供读服务，参与Leader选举过程，参与写操。观察者（ ） Observer服务器为客户端提供读服务，不参与Leader选举过程，不参与。写操作“过半写成功”策略。用于在不影响写性能的前提下提升集群的读性能。作“过半写成功”策略。
Zookeeper三种角色
MrLiar的博客
07-08 2844
1、zk的三种角色： Zookeeper 集群中Server有三种角色，Leader、Follower 和 Observer Leader:负责投投票的发起与决议，更新系统状态，写数据 Follower:用于接收客户端请求并用来返回结果，在选主过程中参与投票 Observer:可以接受客户端连接，将写请求转发给leader节点，但是不参与投票过程，只同步leader状态，主要存在目的就是为了提高读取效率 引进Observer角色作用：Zookeeper需保证高可用和强一致
Zookeeper集群角色
07-19 1624
Zookeeper集群中的机器分为以下三种角色。
精选资源
ZooKeeper-:ZooKeeper源码剖析
03-24
看完之后想写点内容做个笔记，确实发现不好开始。由于ZooKeeper一个完整的逻辑的代码可能在多个线程，多个文件以及多个字节上相互作用，所以如果只讲原理，就很难把原理类似代码对应上；相反，只讲源代码就很难理解...
zookeeper-01.xmind
02-06
zk学习笔记
zookeeper-3.4.9.tar.gz+安装过程笔记.doc
09-08
zookeeper.tar.gz包，及安装使用步骤：1、下载zookeeper.x.x.x.tar.gz,放到虚拟机上 2、解压 3、单机模式 a.在conf目录下，复制zoo_sample.cfg到当前文件夹下命名为zoo.cfg。zookeeper默认使用zoo.cfg配置文件 b....
关于ZooKeeper的角色说明
Tom.Su的博客
05-24 1444
zookeeper是一个分布式的，开放源码的分布式应用协调服务，zookeeper大体包括以下角色： Leader(领导者)：领导者负责进行投票的发起和决议，更新系统状态。 Learner(学习者)： Follower(跟随者)：Follower用于接收客户请求并向客户端返回结果，在选主过程中参与投票。 Observer(观察者)：Observer可以接收客户端连接，将写请求转发给lear
ZooKeeper各服务器角色介绍
coolshyman的博客
08-22 565
在事务请求提交阶段，针对Follower服务器，Leader 仅仅只需要发送一个COMMIT消息，Follower 服务器就可以完成事务请求的提交了，因为在这之前的事务请求投票阶段，Follower已经接收过PROPOSAL消息，该消息中包含了事务请求的内容，因此Follower可以从之前的Proposal缓存中再次获取到事务请求。如果是事务请求，那么Follower就会将该事务请求转发给Leader 服务器，Leader服务器在接收到这个事务请求后，就会将其提交到请求处理链，按照正常事务请求进行处理。
zookeeper角色分类
wyfttp11234的博客
03-19 316
启动 Zookeeper 服务器集群环境后，多个 Zookeeper 服务器在工作前会选举出一个 Leader。选举出 leader 前，所有 server 不区分角色，都需要平等参与投票（ obServer 除外，不参与投票）； 选主过程完成后，存在以下几种角色： 角色 描述 领导者（leader） 1、负责进行投票的发起和决议 2、接收客户端的更新请求，把内...
Zookeeper（22）Zookeeper的Leader、Follower和Observer角色分别是什么？
qq_43012298的博客
01-23 1839
Zookeeper 的架构由 Leader、Follower 和 Observer 三种角色组成，确保数据的一致性和高可用性。通过上述配置和代码示例，可以了解如何配置和使用 Zookeeper 集群，包括连接集群、进行基本的节点操作（创建、读取、更新和删除）以及角色的职责和配置。
ZooKeeper 核心知识全解析：架构、角色、节点与应用
guihong004的博客
01-12 2581
在分布式系统的广袤领域中，ZooKeeper 犹如一颗璀璨的明珠，为众多复杂的协调任务提供了坚实的支持。它以其独特的设计和强大的功能，成为了构建可靠、高效分布式应用的重要基石。无论是实现分布式锁以确保资源的安全访问，还是构建复杂的集群管理机制，ZooKeeper 都发挥着不可或缺的作用。 接下来，让我们深入探索 ZooKeeper 的奇妙世界，详细了解它的分布式锁实现方式、系统架构设计背后的精妙之处、各个角色的独特职责、节点的类型与属性等核心知识，一同揭开 ZooKeeper 的神秘面纱。
Zookeeper与paxos算法
u013738122的博客
09-12 312
原文地址 阅读更多 一、            zookeeper是什么 官方说辞：Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。 好抽象，我们改变一下方式，先看看它都提供了哪些功能，然后再看看使用
【3】Zookeeper中的角色
weixin_30802273的博客
06-22 351
一、Zookeeper角色的分类 领导者（leader） Leader服务器为客户端提供读服务和写服务。 学习者（learner） 跟随者（follower） Follower服务器为客户端提供读服务，参与Leader选举过程，参与写操作“过半写成功”策略。 观察者（observer） Observer服务器为客户端提供读服务，不参与Leader选举过程，不参与写操作“过半写成功”策略。用于在...
ZooKeeper角色体系
NZC2237的博客
12-24 626
Leader 负责事务的处理和数据同步，Follower 负责数据的复制与备份，而 Observer 主要用于提供读请求处理能力的扩展。客户端通过连接到 ZooKeeper 服务器，与这些角色进行交互，实现分布式系统中的协调和一致性管理。Observer 主要用于扩展集群，提供更多的读请求处理能力，减轻 Leader 和 Follower 的压力。在 ZooKeeper 集群中跟随 Leader 的指令，参与事务的处理和数据复制。Leader 负责维护系统的一致性和顺序性，并协调各个节点之间的数据同步。
一文看懂 ZooKeeper ，面试再也不用背八股
the shy
03-11 306
一、ZooKeeper 的工作机制二、ZooKeeper 中的 ZAB 协议三、数据模型与监听器四、ZooKeeper 的选举机制和流程本文将以如下内容为主线讲解ZooKeeper中的学习重点，包括 ZooKeeper 中的角色、ZAB协议、数据模型、选举机制、监听器原理以及应用场景等。会对相关的面试题或开发中常见内容，进行重点讲解。接下来将带领大家入门学习 ZooKeeper 系列的内容，力求通俗易懂，图文并茂。
Zookeeper笔记
渔阳的博客
07-30 1401
zookeeper。
// cluster1 上 将zookeeper 解压到/usr/local 目录下，配置环境变量 # vi /etc/profile // 添加以下内容 export ZOOKEEPER_HOME=/usr/local/zookeeper-3.4.6 export PATH=$ZOOKEEPER_HOME/bin:$PATH # cd /usr/local/zookeeper-3.4.6 // 在 conf 中新建zoo.cfg 文件 # vi conf/zoo.cfg // 输入以下内容 # 客户端心跳时间(毫秒) tickTime=2000 # 允许心跳间隔的最大时间 initLimit=10 # 同步时限 syncLimit=5 # 数据存储目录 dataDir=/home/hadoop_files/hadoop_data/zookeeper # 数据日志存储目录 dataLogDir=/home/hadoop_files/hadoop_logs/zookeeper/dataLog # 端口号 clientPort=2181 # 集群节点和服务端口配置 server.1=cluster1:2888:3888 server.2=cluster2:2888:3888 server.3=cluster3:2888:3888 // 创建 zookeeper 的数据存储目录和日志存储目录 14 大数据技术课程笔记本虚拟机搭建Hadoop集群操作文档 # mkdir -p /home/hadoop_files/hadoop_data/zookeeper # mkdir -p /home/hadoop_files/hadoop_logs/zookeeper/dataLog # mkdir -p /home/hadoop_files/hadoop_logs/zookeeper/logs // 修改文件夹的权限 # chown -R hadoop:hadoop /home/hadoop_files # chown -R hadoop:hadoop /usr/local/zookeeper-3.4.6 // 在 cluster1 号服务器的 data 目录中创建一个文件myid，输入内容为1 // myid 应与zoo.cfg 中的集群节点相匹配 # echo "1" >> /home/hadoop_files/hadoop_data/zookeeper/myid // 修改 zookeeper 的日志输出路径(注意CDH版与原生版配置文件不同) # vi bin/zkEnv.sh // 将配置文件里面的以下项替换为红字的内容 if [ "x${ZOO_LOG_DIR}" = "x" ] then ZOO_LOG_DIR="/home/hadoop_files/hadoop_logs/zookeeper/logs" fi if [ "x${ZOO_LOG4J_PROP}" = "x" ] then ZOO_LOG4J_PROP="INFO,ROLLINGFILE" fi // 修改 zookeeper 的日志配置文件 # vi conf/log4j.properties // 修改为以下内容： zookeeper.root.logger=INFO,ROLLINGFILE log4j.appender.ROLLINGFILE=org.apache.log4j.DailyRollingFileAppender 将这个zookeeper-3.4.6 的目录复制到其他的两个节点上 # scp -r /usr/local/zookeeper-3.4.6 cluster2:/usr/local/ # scp -r /usr/local/zookeeper-3.4.6 cluster3:/usr/local/ // 退回 hadoop 用户 # exit // 刷新环境变量 $ source /etc/profile 完成了这些操作，启动时出现了JMX enabled by default Using config: /usr/local/zookeeper-3.4.6/bin/../conf/zoo.cfg Starting zookeeper ... /usr/local/zookeeper-3.4.6/bin/zkServer.sh: line 113: /home/hadoop_er.pid: Permission denied FAILED TO WRITE PID
最新发布
03-24
<think>嗯，用户遇到了在启动Zookeeper时出现的权限问题，提示无法写入PID文件。首先，我需要理清整个配置过程，看看哪里可能出错了。用户按照步骤解压Zookeeper到指定目录，配置了环境变量，修改了日志路径，并复制到其他节点。然后启动时出现了权限被拒绝的错误，特别是在写入PID文件时。 首先，PID文件通常由Zookeeper的服务脚本zkServer.sh生成，默认路径可能是在数据目录或者Zookeeper的根目录下。用户遇到的错误信息显示路径是/home/hadoop_er.pid，但根据之前的配置，数据目录应该是/home/hadoop_files/hadoop_data/zookeeper，所以这里可能存在路径配置错误或者脚本中的变量问题。 接下来，检查zkServer.sh脚本的第113行。用户提到错误信息指向这一行，可能是因为脚本中设置PID文件的路径时没有正确的变量引用，导致PID文件被尝试写入到没有权限的目录，比如用户主目录而不是指定的数据目录。例如，如果脚本中的PID路径变量未正确配置，可能会默认到当前用户的家目录，而hadoop用户可能没有在该目录写入的权限。 另外，用户使用root用户操作后切换回hadoop用户，可能目录权限设置不当。虽然用户执行了chown -R hadoop:hadoop 对相关目录，但可能PID文件尝试写入的目录没有被正确授权。比如，如果PID文件路径是/home/hadoop_files/hadoop_data/zookeeper，需要确认hadoop用户是否有写权限。 还可能是在环境变量中ZOOPIDFILE没有被正确设置，导致脚本使用默认路径。或者，在zkServer.sh中，生成PID文件的路径拼接错误，比如使用了相对路径，导致实际路径不在预期的位置。 解决方案方面，首先检查zkServer.sh脚本中关于PID文件路径的部分，确认其是否指向了正确的目录，并且hadoop用户有权限写入。可能需要手动设置ZOO_PID_DIR环境变量，或者在脚本中修改PID路径到有权限的目录。另外，确保所有相关目录（如数据目录、日志目录）的所有权和权限正确设置，尤其是执行启动命令的用户是否有足够的权限。</think>以下是针对Zookeeper启动时出现`Permission denied`问题的逐步解决方案： --- ### **问题原因分析** 错误日志`/home/hadoop_er.pid: Permission denied`表明： 1. Zookeeper尝试将进程ID(PID)文件写入到`/home`目录下的`hadoop_er.pid` 2. 当前用户（hadoop）对`/home`目录没有写入权限 --- ### **解决方法** #### **步骤1：定位PID文件路径配置** Zookeeper默认将PID文件存储在`$ZOO_PID_DIR`目录下。检查以下文件配置： ```bash # 查看zkServer.sh中PID路径定义（重点关注第113行） vi /usr/local/zookeeper-3.4.6/bin/zkServer.sh ``` 找到类似以下配置片段： ```bash ZOO_PID_DIR="$(dirname "$ZOO_PIDFILE")" ``` --- #### **步骤2：修改PID文件存储路径** 需将PID文件存储到有权限的目录（如Zookeeper数据目录）： ```bash # 编辑zkServer.sh，在文件开头添加环境变量定义 export ZOO_PID_DIR=/home/hadoop_files/hadoop_data/zookeeper export ZOO_PID_FILE=$ZOO_PID_DIR/zookeeper_server.pid ``` 或直接在脚本中找到`ZOO_PIDFILE`赋值行，修改为： ```bash ZOO_PIDFILE="$ZOO_PID_DIR/zookeeper_server.pid" ``` --- #### **步骤3：验证目录权限** 确保目标目录归属hadoop用户且权限正确： ```bash # 检查目录所有权 chown -R hadoop:hadoop /home/hadoop_files # 检查目录权限（需至少755） chmod 755 /home/hadoop_files/hadoop_data/zookeeper ``` --- #### **步骤4：同步修改到所有节点** ```bash # 将修改后的zkServer.sh复制到其他节点 scp /usr/local/zookeeper-3.4.6/bin/zkServer.sh cluster2:/usr/local/zookeeper-3.4.6/bin/ scp /usr/local/zookeeper-3.4.6/bin/zkServer.sh cluster3:/usr/local/zookeeper-3.4.6/bin/ ``` --- #### **步骤5：重新启动Zookeeper** ```bash # 切换回hadoop用户 su hadoop # 启动服务（需在所有节点执行） zkServer.sh start # 检查状态 zkServer.sh status ``` --- ### **补充说明** 1. **日志路径问题**：如果仍存在日志权限错误，检查`ZOO_LOG_DIR`配置： ```bash # 确保日志目录存在且可写 mkdir -p /home/hadoop_files/hadoop_logs/zookeeper/logs chmod 755 /home/hadoop_files/hadoop_logs/zookeeper/logs ``` 2. **配置一致性**：所有节点的`myid`文件需分别设置为1、2、3，且与`zoo.cfg`中`server.x`对应 --- 通过以上步骤，权限问题应得到解决。如果仍报错，可通过`tail -f /home/hadoop_files/hadoop_logs/zookeeper/logs/zookeeper.log`查看详细日志。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值