如何查看HDFS默认的nameservices命名空间
查看HDFS的默认命名空间命令：
1 | hdfs getconf -confKey fs.default.name |
或者
1 | hdfs getconf -confKey fs.defaultFS |
或者查询core-site.xml中的dfs.nameservices的值。
1 | hdfs getconf -confKey dfs.nameservices |
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 码农笔记！
wechat
alipay
相关推荐
2017-07-21
查看修复HDFS中丢失的块
检测缺失块1hdfs fsck -list-corruptfileblocks 1hdfs fsck / | egrep -v '^\.+$' | grep -v eplica 查看上面某一个文件的情况 1hdfs fsck /path/to/corrupt/file -locations -blocks -files 解决方法如果文件不重要，可以直接删除此文件；或删除后重新复制一份到集群中如果不能删除，需要从上面命令中找到发生在哪台机器上，然后到此机器上查看日志。 参考 http://centoshowtos.org/hadoop/fix-corrupt-blocks-on-hdfs/ http://stackoverflow.com/questions/19205057/how-to-fix-corrupt-hadoop-hdfs
2023-06-20
Kerberos认证后访问HDFS提示Not attempting to re-login错误
场景CDH6.3.4集群，开通了Kerberos认证，在客户端得机器上已经通过了Kerberos得认证并且缓存了票据。 由于是新装的系统，安装了最新的jdk-8u371。 报错执行hdfs dfs -ls / 命令频繁的打印如下错误： 1org.apache.hadoop.security.UserGroupInformation Not attempting to re-login since the last re-login was attempted less than 600 seconds before 错误原因找了很久，忽然想到了曾经遇到过这种问题，是JDK版本太低导致的，但我安装了最新的JDK1.8，那就有可能是JDK版本太高导致的。 解决办法下载了一个jdk-8u221版本，完美解决问题。CDH虽然写了支持JDK1.8，但小版本也会影响到它的正常运行，所以以后遇到类似得情况先调整下JDK版本，别太高也别太低。最好是看下官方有没有推荐的版本。
2018-05-21
Hadoop Timed out waiting 20000ms
今天发现测试环境Hadoop集群开始频繁宕掉，查看namenode日志发现有如下报错信息： 1java.io.IOException: Timed out waiting 20000ms for a quorum of nodes to respond. 原因是因为namenode与journalnode通信时，超过20000ms，触发了默认设置的超时时长，解决办法：在hdfs-site.xml中加入如下配置 123456789101112<property> <name>dfs.qjournal.start-segment.timeout.ms</name> <value>90000</value></property><property> <name>dfs.qjournal.select-input-streams.timeout.ms</name> <value>90000</value></property&...
2017-07-21
Hadoop命令-fsck
在HDFS中，提供了fsck命令，用于检查HDFS上文件和目录的健康状态、获取文件的block块信息和位置信息等。 具体命令介绍： -move: 移动损坏的文件到/lost+found目录下-delete: 删除损坏的文件-openforwrite: 输出检测中的正在被写的文件-list-corruptfileblocks: 输出损坏的块及其所属的文件-files: 输出正在被检测的文件-blocks: 输出block的详细报告 （需要和-files参数一起使用）-locations: 输出block的位置信息 （需要和-files参数一起使用）-racks: 输出文件块位置所在的机架信息（需要和-files参数一起使用） 例如要查看HDFS中某个文件的block块的具体分布，可以这样写：hadoop fsck /your_file_path -files -blocks -locations -racks示例： 1234567891011121314151617181920212223242526#hdfs fsck /tmp/test/input...
2017-07-13
关闭Hadoop集群时提示no xxx to stop
今天迁移机器的时候，需要手动关闭所有的机器。那么关机之前当然是要先安全的关闭hadoop的相关服务，但是由于这个集群不是我搭建的，发现有些机器在关闭集群的时候出现no xxx to stop，就我发现的来说有namenode，journalnode，jobtracker这三个。 问题的原因Hadoop在stop的时候依据的是启动是保存到pid文件的pid.而默认的进程号保存在/tmp下，Linux 默认会每隔一段时间（一般是一个月或者7天左右）去删除这个目录下的文件。因此删掉pid文件后，namenode自然就找不到datanode上的这个进程了。(不同的进程的进程id文件名会有变化) 解决办法临时解决针对这次集群关闭,我们需要做的是:首先保证集群没有负载,然后去手动杀死datanode/journalnode/zkfc最后去杀死namenode(注意顺序) 永久解决在配置文件hadoop_env.sh中配置export HADOOP_PID_DIR可以解决这个问题。
2017-07-21
Journal Storage Directory not formatted
Hadoop启动的时候发现JournalNode节点一直启动不起来，查看后台日志发现异常信息JournalNode not formatted,通常这种异常大概有如下三种情况导致的： 新搭建的集群，我配置的时候没有吧fs.defaultFS配置一致，导致执行hadoop命令的时候报错，后来修改了以后重启集群就出现这个问题了，此时需要重新格式化namenode，因为在格式化namenode的时候，就顺便把JournalNode格式化了。 如果是正在用运行的集群，其中一台机器的JournalNode没有被格式化，那么检查完权限没问题以后，从其他JournalNode复制一份到没有格式化的JournalNode。 如果是从no-HA更新到HA，只需要执行如下命令： 1hdfs namenode -initializeSharedEdits 也就是你可以不用格式化NameNode就可以格式化你的JournalNode目录
评论
