Aliyun Code

首页  >   chuyu / tfs

项目语言:c

创建者:chuyu 创建时间:2012年04月22日

常见编译错误

  1. 出现类似于cannot convert 'uint64_t*' to 'uLongf*' for argument的错误

通常是gcc版本较高的问题,建议回退到4.1.2版本

  1. 出现类似于error: uuid/uuid.h: No such file or directory的错误

未安装libuuid-devel

  1. 出现类似于undefined reference to `mysql_query'的错误

查看是否安装了mysql-devel

  1. 出现类似警告:格式 ‘%lu’ 需要类型 ‘long unsigned int’,但实参 3 的类型为 ‘size_t’

查看是否是32位机

  1. 出现类似tbnet.h:39: fatal error: tbsys.h: No such file or directory的错误

没有编tb-common-util,tfs要先安装tbnet和tbsys。

常见集群问题

format失败

  1. ERROR create_block (blockfile_manager.cpp:1139) allocate space error. ret: -1, error: 95, error desc: Operation not supported create tfs file system fail. ret: -1

base_filesystem_type配置错误。

  1. ERROR create_fs_dir (blockfile_manager.cpp:1021) make extend dir:/var/file1/extend/ error. ret: -1, error: 17 create tfs file system fail. ret: 1

数据目录已经存在,先clear再format
具体的error可以查看linux的errno值,再做判断。

写超时

  1. 如果是新建的集群,还没有写入过文件的

a) 出现5001的错误,则先用ssm看一下server是否挂上来了,如果都挂上了,看block是否创建出来了。
如果没有block则看一下nameserver的日志,看一下原因。一般如果已经过了safe_mode_time,还没有创建出来的话,就要看一下add block失败的原因了。
b)看一下配置文件,min_replicate和max_replicate是否配置正确

  1. 如果是已经了运行一段时间的集群

a)查看server及客户端机器网络是否正常
b)是否用小文件接口写大文件
c)看一下错误日志,是否集中在某几台机器上,如果是,看一下磁盘是否有问题,如变成readonly,是否有core等。

读超时

  1. 先根据错误判断block的状态,用tfstool看文件信息及block状态。

如果block还存在,那么去对应的ds上看访问信息。如果不存在该block,则通过ns日志看block的情况。

  1. 2.2.1没有真正的实现retry读,如果主副集群不一致,那么如果就近读的集群读不到的话就会出现8025错误,这个时候就需要先把这部分的文件同步过去,并查看同步队列是否堵上了。

block写满

  1. 看一下配置文件ns.conf中block_max_size配置是否正确,ns根据此来判断block是否满了
  2. block真的满了?需要扩容。

集群满了

  1. 看 block_max_size是否配置过大,导致使用大量扩展块。
  2. 是否有大量更新操作,导致使用大量扩展块。

扩展块使用比例可使用read_super_block工具查看。

Too many open files

用ulimit -a查看open files 的值,看是否配置过小,建议配置值65535。

cannot elect move dest server block

无法选出做均衡的默认机器。当集群机器数较小时,更容易出现。可以将balance_percent参数调大(如:0.01),避免在稍有不均衡时就创建均衡计划。

出现remote/block version is larger

日志中上述错误,说明block在dataserver和nameserver的版本不一致。
不一致的情况有很多,需要根据集群运行具体分析。
比如,当出现在某一次写操作时,一个副本成功,一个副本失败,那么这时成功的副本block ds version会比ns上的高;而当ds宕机时block有更新(在另一台ds上),那么ds重新挂上了时,block ds version会比ns上的低。

集群常见错误处理

5003

常见于应用在读文件或更新文件的时候出现,表示block在nameserver上没有记录。

  1. 确认该block是否是合法blockid,如果blockid明显过大,则忽略,否则进入下一步。若是更新操作的话,一般可以直接进入下一步
  2. 看主副集群上是否有该blockid,若只有其中一个集群中不存在,那么从对应集群用sync_by_blk

工具同步过来。
搜索nameserver日志,可以把这部分的block都拉出来同步一把。

  1. 查看日志删除记录,查一下什么原因丢的这个block,视具体情况而定。

5002

常见于应用在读文件或更新的时候出现,表示block在nameserver上没有和ds的关联关系,但block自身结构依然存在。

  1. 查看对应集群上是否还有该blockid,若还有,则先用admintool工具removeblk该block,再从对应集群用sync_by_blk工具同步过来。

搜索nameserver日志,可以把这部分的block都拉出来先删除再同步一把。

  1. 查看日志删除记录,查一下什么原因丢的这个block,视具体情况而定。

retry_count

当日志中出现这个关键词,说明同步日志有可能堵上了。

  1. 看一下retry_count的次数,如果3次左右成功了,那有可能是在操作同一个block或是网络问题,确认一下就可以忽略。

如果一直在同步同一个文件,那么说明队列已经拥堵,进入下一步。

  1. 查看retry_count该行日志返回的错误信息,看是源集群的机器堵上了,还是目标集群的机器堵上了。

一般堵上有可能是死锁问题或是磁盘问题(如readonly)。视具体情况处理

  1. 启用recover_sync_file_queue工具疏通队列,再观察一下集群情况。

lost

nameserver日志中出现这种错误,说明这个block在nameserver中之前存在,现在没有备份了,这种情况会引起5002或5003。

  1. 查看日志中是否有机器宕机,如果该block只有单个备份的话,机器宕机就会lost block。
  2. 查看日志中有没有delete该block的记录,有的话,查看为什么有这种情况。

曾经遇到一种情况是block单备份进行紧急复制,但是block所在的源ds向ns汇报失败,ns重复向源ds发送紧急复制请求,导致目标ds重复add,delete。这时源ds磁盘坏了,目标ds上block正好被删除(复制前会先检查block是否存在,如果存在,则先删除),block就lost了。
具体情况要分析日志进行相应处理。

  1. 坏盘的情况可以用运维平台坏盘先处理(目前不可用),其它情况可以先到对应集群用sync_by_blk工具同步过来。

设计相关

关于tfs的删除机制

tfs在调用unlink接口时只会在现在文件的fileInfo的flag上打删除标志,真正的删除需要通过nameserver的compact计划来完成。也就是说当block的文件删除个数或文件删除容量到达一定比例时,nameserver会创建compact计划清理block,这个时候是真正的删除。
具体创建计划代码可以参见src/nameserver/layout_manager.cpp build_compact_task_函数
具体compact实现可以参见src/dataserver/compact_block.cpp