记一次Alluxio HA master启动失败

1. 今天遇到一个情况,就是alluxio不能正常访问,经过日志查看,发现下面错误。

2018-05-14 03:35:58,680 ERROR logger.type (HdfsUnderFileSystem.java:open) - 4 try to open hdfs://sandy-bridge/user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001 : Cannot obtain block length for LocatedBlock{BP-1941630157-10.16.13.73-1486732586674:blk_1322900685_252817168; getBlockSize()=254; corrupt=false; offset=0; locs=[10.16.13.189:1019, 10.16.13.84:1019, 10.16.13.128:1019]; storageIDs=[DS-30126b4d-afdf-449a-8de1-e479c1abf33d, DS-ed2e905e-fa43-4f51-801f-3305da180d2a, DS-0e1946c8-dccb-4143-8d74-c11d8d429d02]; storageTypes=[DISK, DISK, DISK]}
java.io.IOException: Cannot obtain block length for LocatedBlock{BP-1941630157-10.16.13.73-1486732586674:blk_1322900685_252817168; getBlockSize()=254; corrupt=false; offset=0; locs=[10.16.13.189:1019, 10.16.13.84:1019, 10.16.13.128:1019]; storageIDs=[DS-30126b4d-afdf-449a-8de1-e479c1abf33d, DS-ed2e905e-fa43-4f51-801f-3305da180d2a, DS-0e1946c8-dccb-4143-8d74-c11d8d429d02]; storageTypes=[DISK, DISK, DISK]}
at org.apache.hadoop.hdfs.DFSInputStream.readBlockLength(DFSInputStream.java:400)
at org.apache.hadoop.hdfs.DFSInputStream.fetchLocatedBlocksAndGetLastBlockLength(DFSInputStream.java:305)
at org.apache.hadoop.hdfs.DFSInputStream.openInfo(DFSInputStream.java:242)
at org.apache.hadoop.hdfs.DFSInputStream.<init>(DFSInputStream.java:235)
at org.apache.hadoop.hdfs.DFSClient.open(DFSClient.java:1487)
at org.apache.hadoop.hdfs.DistributedFileSystem$3.doCall(DistributedFileSystem.java:302)
at org.apache.hadoop.hdfs.DistributedFileSystem$3.doCall(DistributedFileSystem.java:298)
at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at org.apache.hadoop.hdfs.DistributedFileSystem.open(DistributedFileSystem.java:298)
at org.apache.hadoop.fs.FileSystem.open(FileSystem.java:766)
at alluxio.underfs.hdfs.HdfsUnderFileSystem.open(HdfsUnderFileSystem.java:387)
at alluxio.underfs.BaseUnderFileSystem.open(BaseUnderFileSystem.java:124)
at alluxio.master.journal.JournalReader.getNextInputStream(JournalReader.java:114)
at alluxio.master.journal.JournalTailer.processNextJournalLogFiles(JournalTailer.java:118)
at alluxio.master.AbstractMaster.start(AbstractMaster.java:140)
at alluxio.master.file.FileSystemMaster.start(FileSystemMaster.java:419)
at alluxio.master.DefaultAlluxioMaster.startMasters(DefaultAlluxioMaster.java:263)
at alluxio.master.FaultTolerantAlluxioMaster.start(FaultTolerantAlluxioMaster.java:91)
at alluxio.ServerUtils.run(ServerUtils.java:38)

2. 首先是怀疑文件log.00000000000000000001损坏,经过hfs fsck的检查,并没有发现corruption,但是Total size: 0,这是个问题。

[[email protected] hdfs]$ hdfs fsck /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001
Connecting to namenode via http://hdfs-namenode.eu-central-1.compute.internal:50070/fsck?ugi=hdfs&path=%2Fuser%2Falluxio%2Fjournal%2FFileSystemMaster%2Fcompleted%2Flog.00000000000000000001
FSCK started by hdfs (auth:KERBEROS_SSL) from /10.16.13.73 for path /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001 at Mon May 14 03:53:11 UTC 2018
Status: HEALTHY
Total size: 0 B (Total open files size: 254 B)
Total dirs: 0
Total files: 0
Total symlinks: 0 (Files currently being written: 1)
Total blocks (validated): 0 (Total open file blocks (not validated): 1)
Minimally replicated blocks: 0
Over-replicated blocks: 0
Under-replicated blocks: 0
Mis-replicated blocks: 0
Default replication factor: 3
Average block replication: 0.0
Corrupt blocks: 0
Missing replicas: 0
Number of data-nodes: 41
Number of racks: 1
FSCK ended at Mon May 14 03:53:11 UTC 2018 in 1 milliseconds
The filesystem under path '/user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001' is HEALTHY

3. 将这个问题件mv走,再启动alluxio HA master,启动成功。

[[email protected] hdfs]$ hdfs dfs -mv /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001 /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001.bak
[[email protected] hdfs]$ hdfs dfs -ls /user/alluxio/journal/FileSystemMaster/completed/
Found 2 items
-rw-r--r-- 3 alluxio alluxio 254 2018-01-29 09:32 /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001.bak
-rw-r--r-- 3 alluxio alluxio 397 2018-05-14 03:03 /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000002

4. 其中尝试过,将文件再mv回来,但是alluxio依然启动失败,还是最开始的错误。

5. 直接cat这个文件,发现也不能访问。

hdfs dfs -cat /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000001.bak
cat: Cannot obtain block length for LocatedBlock{BP-1941630157-10.16.13.73-1486732586674:blk_1322900685_252817168; getBlockSize()=254; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[10.16.13.189:1019,DS-30126b4d-afdf-449a-8de1-e479c1abf33d,DISK], DatanodeInfoWithStorage[10.16.13.128:1019,DS-0e1946c8-dccb-4143-8d74-c11d8d429d02,DISK], DatanodeInfoWithStorage[10.16.13.84:1019,DS-ed2e905e-fa43-4f51-801f-3305da180d2a,DISK]]}

6. 而正常的文件,输出如下:

[[email protected] hdfs]$ hdfs dfs -cat /user/alluxio/journal/FileSystemMaster/completed/log.00000000000000000002
NOT_PERSISTED(0,@ HPXhdatadownloadz_20180510130731077.zip"
NOT_PERSISTED(0,@ HPXhdatadownloadzdatadownload Z 6Perrier_%3F%3F_20180101_20180104_20180510130731077.zip"
NOT_PERSISTED(0,@ HPXhdatadownloadzdatadownload Z 6Perrier_%3F%3F_20180101_20180104_20180510130731077.zip"
NOT_PERSISTED(0,@ HPXhdatadownloadzdatadownload Z 6Perrier_%3F%3F_20180101_20180104_20180510130731077.zip"
NOT_PERSISTED(0,@ HPXhdatadownloadz datadownload Z 6Perrier_%3F%3F_20180101_20180104_20180510130731077.zip"

7. Alluxio master是启动成功了,但是丢了一部分数据。

这个问题,有时间,还要继续研究一下,看是否能将数据找回。

原文地址:http://blog.51cto.com/hsbxxl/2116255

时间: 2024-12-15 23:57:09

记一次Alluxio HA master启动失败的相关文章

Alluxio HA 写入文件失败

Alluxio HA环境,今天发生,用户无法写入文件的情况. 创建文件夹,是正常的.但是最后copyFromLocal 文件的时候,就没有任何反应.最后可以看到这个新建的文件.但是文件size是0. alluxio fs copyFromLocal test.txt /user/mytest/prefix2 最后决定重启一下master看看结果.然后重启,然后...就没有然后了.....Master起不来了!!!! 查看master.log发现问题,刚开始,是正常的应用log file,在 in

记一次centos6升级salt-minion启动失败的问题

记一次centos6升级salt-minion启动失败的问题 作者:耀耀 blog:https://www.liuyao.me 一.起因 升级Salt-minion后 使用/etc/init.d/salt-minion start启动失败,报错如下 [root@admin]# /etc/init.d/salt-minion start ERROR: Unable to look-up config values for /etc/salt 二.排查 刚开始觉得此错误应该是因minion配置文件有

Greenplum启动失败Error occurred: non-zero rc: 1的修复

某日开发反馈测试环境的集群启动失败 报错内容如下: [[email protected]:/root]$ gpstart 20181205:16:42:23:005451 gpstart:hadoop-test2:gpadmin-[INFO]:-Starting gpstart with args: 20181205:16:42:23:005451 gpstart:hadoop-test2:gpadmin-[INFO]:-Gathering information and validating

kudu-master服务启动失败

执行service kudu-master start ,  提示启动失败failed. 进入报错日志目录  (cd /var/log/kudu/),看到报错信息(vim kudu-master.ERROR 或 vim kudu-master.FATAL)如下: Log file created at: 2019/10/23 19:04:52Running on machine: cdh01.itcast.cnLog line format: [IWEF]mmdd hh:mm:ss.uuuuuu

【原创】大叔经验分享(98)mesos slave启动失败

mesos slave启动失败,查看状态如下: # systemctl status mesos-slave ● mesos-slave.service - Mesos Slave Loaded: loaded (/usr/lib/systemd/system/mesos-slave.service; enabled; vendor preset: disabled) Active: activating (auto-restart) (Result: exit-code) since Sat

Mongodb分片配置服务器不同步导致mongos进程启动失败

生产环境中,使用的mongodb分片,由于突然断电,服务再起来的时候发现三个mongos进程中有一个启动失败,多次尝试仍不能启动.查看日志,内容如下: 大概意思是配置服务器configserver数据不同步. 解决办法: 杀死所有mongos进程 连接到每个分片的configserver,运行命令db.runCommand('dbhash') 找到MD5值,这时两个能正常运行的MD5值是一样的,不能正常运行的MD5和上面俩都不一样 删除不能正常运行的dbpath,将能正常运行的dbpath下的数

多学一点(十三)——解决Linux kdump服务启动失败

kdump 是 Linux Kernel 崩溃时的转储机制,简单理解就是在系统启动过程中如果 Kernel 因为某些原因崩溃了,kdump 就会负责记录日志以便排查原因.在 CentOS 6 等 Linux 发行版中,即便采用最小化安装, kdump 也会作为服务安装到系统中,此时可能因为我们对 Linux分配的内存的限制导致 kdump 服务开机启动失败,如图 1 所示: 图-1 kdump启动失败 解决 kdump 启动失败其实很简单,只要修改 grub.conf 文件,改变crashker

ORA-01078和LRM-00109问题导致ORACLE启动失败解决方法

操作环境 SuSE11 + ORACLE11gR2(11.2.0.3) 问题现象 新安装ORACLE启动失败,提示ORA-01078和LRM-00109错误.具体错误现象如下 SQL> startup ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/home/oracle/base/dbs/initora11g.ora'  问题分析 根据错误分析是查找不到参

CentOs 6.6里kdump启动失败的原因

在VMware中新安装了CentOs 6.6,重启系统发现kdump服务启动失败 先来说一下,什么是kdump kdump 是一种先进的基于 kexec 的内核崩溃转储机制.当系统崩溃时,kdump 使用 kexec 启动 到第二个内核.第二个内核通常叫做捕获内核,以很小内存启动以捕获转储镜像.第一个内核保 留了内存的一部分给第二内核启动用.由于 kdump 利用 kexec 启动捕获内核,绕过了 BIOS,所 以第一个内核的内存得以保留.这是内核崩溃转储的本质. 启动失败的原因 查看 /etc