MooseFS使用问题分析总结

简介:

随着数据量越来越大,MFS的使用中也出现过一些问题,这里做了一些分析和总结,下面和大家分享一下:

先提一下MFS出问题时出现比较频繁的两个信息:

  • 连接中断

  • 坏块问题

连接中断问题在Master端会出现如下错误:

  1. mfsmaster[15861]: connection with client(ip:10.11.18.175) has been closed by peer  

  2. 表示客户端和master的连接中断  

  3. mfsmaster[15861]: connection with ML(10.11.19.76) has been closed by peer  

  4. 表示Metalogger和Master的连接中断  

  5. mfsmaster[15861]: connection with CS(10.11.18.199) has been closed by peer  

  6. 表示ChunkServer和Master的连接中断 

原因分析可能如下:

  1. 网络闪断 - 正常现象,MFS本身可自动重连,不会造成问题

  2. Clinet或ChunkServer主动断开连接,如Kill进程,也会引起这种错误

  3. ChunkServer或Client到Master的连接超时,也会断开连接,引起超时可能有两个原因:

  • Client请求过多,引起Master请求队列已满,导致的连接超时

  • 网络响应慢引起的超时(和网络闪断区分)

解决办法:

  • 对于1、3出现引起的中断可不加理会,重点需关注2引起的问题:

  • 针对2-a:Client控制请求,如超高并发的读写删除,另需注意的操作是ls,大家知道Linux系统本身对一个目录下文件个数的显示是有限制的(如10W,那么涉及到的需遍历指令就会报错,list too long),同样,我们MFS中遍历目录下文件时也要注意,要遍历的文件数过多会导致超时引起连接被中断等问题。

  • 针对2-b: 合理分配带宽资源,优化网络环境解决。

备注:

Client或Chunk到Master的连接中断之后,会由Client或Chunk自动发出重连(Reconnection)和注册(Register)操作。

坏块问题在Master端会出现如下错误:

  1. mfsmaster[3250]: chunkserver has nonexistent chunk (000000000002139F_00000001), so create it for future deletion  

  2. mfsmaster[3250]: (10.11.18.199:9422) chunk: 000000000002139F creation status: 20  

  3. mfsmaster[3250]: chunk 000000000002139F has only invalid copies (1) – please repair it manually  

  4. mfsmaster[3250]: chunk 000000000002139F_00000001 – invalid copy on (10.11.18.199 – ver:00000000)  

  5. mfsmaster[3250]: currently unavailable chunk 000000000002139F (inode: 135845 ; index: 23) 

上述日志的意思是:有一个块在Master中有元数据信息,但ChunkServer中没有这个块,系统会自动在ChunkServer上创建此块为了后续删除,因为没有内容,所以是非法的copy,我们也无法访问到此块。

出现的原因可能有很多,如:

  • Client端大文件传输过程中,强制拔下master主机电源,造成master非法关闭,使用mfsmetarestore -a修复后,master日志报告有坏块

  • ChunkServer的csstats.mfs存放位置空间不足,导致文件块无法写入,也会引起块错误

  • 手动删除ChunkServer上的块文件

  • 删除文件后,Master非正常结束后重启,但没有结果changelog.mfs进行恢复,也会引起坏块

原因应该还有很多,后续有遇到再补充。

解决办法:

Client端使用mfsfilerepair对文件进行修复。

我理解坏块分为两种:

  • 一种是没有任何一个trunk节点有数据(修复工作其实就是生成chunk,在需要补充内容的地方填充0,这种块事后要删除)

  • 另一种是存在有数据块的节点(从存在的数据块copy,这里的块不需要删除)

修复之后可能出现如下日志信息:

  1. mfsmaster[3250]: chunk hasn’t been deleted since previous loop – retry  

  2. mfsmaster[3250]: (10.11.18.199:9422) chunk: 000000000002139F deletion status: 13 

Client端执行一个mv或rm 操作,master将不会再显示此信息,如:

  1. mv 80499644316259743_s.jpg 80499644316259743_s_1.jpg 






     本文转自yzy121403725 51CTO博客,原文链接:http://blog.51cto.com/lookingdream/1831815,如需转载请自行联系原作者




相关文章
|
10月前
|
测试技术
fio磁盘压测工具
因为是虚拟机,所以对于性能很虚。借助fio进行测试
607 0
|
7天前
|
监控 负载均衡 安全
Elasticsearch 集群某一节点修改 IP 后无法启动问题复盘
Elasticsearch 集群某一节点修改 IP 后无法启动问题复盘
31 2
|
缓存 块存储 开发工具
CephFS 常用命令以及问题分析
最近公司的生产环境已经开始使用 CephFS 作为文件系统存储,记录一下使用过程中遇到的问题,已经一些常用的命令。
3136 0
|
存储 运维 Linux
RH236GlusterFS排错
RH236GlusterFS排错
164 0
RH236GlusterFS排错
|
关系型数据库 MySQL Linux
linux环境下 xampp mysql 启动失败问题排查 日志文件过大占用存储空间导致网站瘫痪
问题现象 网站莫名其妙的连接不上mysql了,导致网站瘫痪;没有改任何程序,怎么回事呢?马上用xshell 和xftp工具连接linux服务器来排查问题 启动xampp mysql /opt/lampp/lampp startmysql 启动xampp mysql ![/opt/lampp/bin/mysql.
2840 0
|
存储 监控 Linux
一次Hbase删库的故障恢复--Linux EXT4 文件恢复原理分析
一次Hbase删库的故障恢复中,采用了特征码扫描的方式,这里描述了决定技术方案的Linux EXT4 文件恢复原理。
2304 0
|
SQL 监控 关系型数据库
|
固态存储 测试技术 Linux