Hypertable运维中遇到的问题

客官°小女子只卖身不卖艺 2022-08-27 08:48 175阅读 0赞

**1.failed expectation: insert\_result.second**

**版本：0.9.7.5之前**

**问题描述：**

在自动failover进行的过程中，手动将之前出问题的机器带回集群，Master日志中出现了如下类似错误：

(/root/src/hypertable/src/cc/Hypertable/Master/RangeServerConnectionManager.cc:50) Contains rs5 host=dlxa125 local=0.0.0.0:0 public=\*.\*.\*.\*:38060  
 FATAL Hypertable.Master : (/root/src/hypertable/src/cc/Hypertable/Master/RangeServerConnectionManager.cc:52) failed expectation: insert\_result.second

**解决方法：**

有两种解决方法：

1）. 社区已经在0.9.7.5版本中解决了这个问题，升级到该版本或者之后的版本；

2）. 也可以在自动failover完成后，再手动带回之前出问题的机器。**不建议在自动failover未完成时执行带回操作，这样有百害而无一利**。

**2.failed expectation: m\_trailer.filter\_items\_estimate**

**版本：0.9.6.5**

**问题描述：**

RangeServer日志中出现了如下类似错误，重启亦是如此：

FATAL Hypertable.RangeServer : (/root/hypertable/src/cc/Hypertable/RangeServer/CellStoreV6.cc:502) failed expectation: m\_trailer.filter\_items\_estimate

**解决方法：**

社区已经在0.9.7.0版本中解决了这个问题，升级到该版本或者之后的版本

**3.select的limit子句bug**

**版本：0.9.7.12以前**

**问题描述：**

limit 1返回结果集为空，但是limit 2却能得到非空的结果集。

**解决方法：**

这是一个bug（issue1175），社区已经在0.9.7.14版本中解决了这个问题，升级到该版本或者之后的版本

**4.从0.9.7.11升级到0.9.7.14后入库速度变慢**

**版本：0.9.7.13--0.9.7.16**

**问题描述：**

从0.9.7.11升级到0.9.7.14后发现入库速度变慢，但是升级到0.9.7.12的入库速度正常

**解决方法：**

这是一个bug（issue1179），发现涉及的版本包括0.9.7.13-0.9.7.16。社区已经在0.9.7.17版本中解决了这个问题，升级到该版本或者之后的版本

**5. failed expectation: split\_row.compare(end\_row)<0 && split\_row.compare(start\_row) > 0**

**版本：0.9.7.12**

**问题描述：**

RangeServer日志中出现了如下类似错误，重启亦是如此：

(root/src/hypertable/src/cc/Hypertable/RangeServer/range.cc 1028) failed expectation: split\_row.compare(end\_row)<0 && split\_row.compare(start\_row) > 0

**解决方法：**

这是一个bug（issue1193），该bug触发条件为：未开启自动failover时，如果个别RangeServer节点挂了，虽然导致了大量入库阻塞，但是部分机器还是可以写入，于是写入的数据持久化到commit log之后就会引起这个bug。有两种解决方法：

1）社区已经在0.9.7.17版本中解决了这个问题，升级到该版本或者之后的版本

2）如果不能升级，可以手动删除出问题RangeServer的所有 commit log文件，此方法虽然可以规避bug，但是代价是损失了一些数据。

**6. Dfsbroker进程占据了太多的端口，导致其它进程不能启动**

**版本：0.9.7.12**

**问题描述：**

发现RangeServer机器上的MapReduce程序不能启动，分析后发现是因为启动时获取不到端口。假设Dfsbroker进程ID为5000，执行下列命令可查看该进程占据了多少端口：

\[root@HadoopServer122 ~\]\# netstat -antup|grep 5000|wc -l  
42911     //我们当时查看到的占据的端口数

**解决方法：**

这是一个bug（issue1197），但不确定社区是否做了修补，因为这个问题很难重现。可以重启dfsbroker来解决此问题。

**7. failed expectation: \*ptr == Key::AUTO\_TIMESTAMP || \*ptr == Key::HAVE\_TIMESTAMP**

**版本：0.9.7.12**

**问题描述：**

RangeServer日志中出现如下类似错误：

(/root/src/hypertable/src/cc/Hypertable/RangeServer/RangeServer.cc:1958)failed expectation: \*ptr == Key::AUTO\_TIMESTAMP || \*ptr == Key::HAVE\_TIMESTAMP

**解决方法：**

对此错误，社区说明可以总结为以下三点：

1）触发条件：当插入cell的timestamp为TIMESTAMP\_NULL（源码中定义的一个常量）时，会引发这个错误；

2）当前触发时机不合理，即不应该在RangeServer端抛出这个错误，应该在客户端写入时抛出这个错误；

3）将在0.9.7.17中修改为合理的触发时机。

但是我按照上述触发条件模拟时，没有看到这个错误。并且在0.9.7.17中仍然看到了这个错误。社区承认在0.9.7.17中修改时有遗漏，承诺在0.9.8.0中修补此遗漏。

虽然当前此问题没有彻底解决，但是重启RangeServer时此问题不是必现问题，既可以通过重启RangeServer规避此问题。

**8. failed expectation: m\_last\_collection\_time**

**版本：0.9.7.17**

**问题描述：**

当减少一个表的TTL属性值后，例如：表TAB\_TEST原TTL为10 day，执行Alter table TAB\_TEST modify (F1 TTL=5 day)修改为5 day，RangeServer中出现如下错误：

FATAL Hypertable.RangeServer :(/root/src/hypertable/src/cc/Hypertable/RangeServer/AccessGroupGarbageTracker.cc:132)failed expectation: m\_last\_collection\_time

**解决方法：**

社区说当上述的alter语句执行后，会在表中增加一个名称为default的新的access group，所以后续对其执行gc引起发这个assert。社区已经在0.9.7.18中修补了这个问题，升级到该版本或者之后的版本可以避免此问题。

**9. Error reading directory entries for DFS directory: /hypertable/servers/rs\*/log/tab\_id/endrow**

**版本：0.9.7.0以前**

**问题描述：**

RangeServer启动后又会挂掉，日志中具有类似于如下的提示：  
ERROR Hypertable.RangeServer :local\_recover (/root/src/hypertable/src/cc/Hypertable/RangeServer/RangeServer.cc:908): Hypertable::Exception: Error reading directory entries for DFS directory: /hypertable/servers/rs8/log/3/19/mhXJ7oobjVGJEjtY-1356744895 - DFS BROKER file not found  
at void Hypertable::CommitLogReader::load\_fragments(Hypertable::String, Hypertable::CommitLogFileInfo\*) (/root/src/hypertable/src/cc/Hypertable/Lib/CommitLogReader.cc:204)  
at virtual void Hypertable::DfsBroker::Client::readdir(constHypertable::String&, std::vector<std::basic\_string<char, std::char\_traits<char>, std::allocator<char>>, std::allocator<std::basic\_string<char, std::char\_traits<char>, std::allocator<char>>>>&) (/root/src/hypertable/src/cc/DfsBroker/Lib/Client.cc:621): Error reading directory entries for DFS directory: /hypertable/servers/rs8/log/3/19/mhXJ7oobjVGJEjtY-1356744895  
at virtual void Hypertable::DfsBroker::Client::readdir(constHypertable::String&, std::vector<std::basic\_string<char, std::char\_traits<char>, std::allocator<char>>, std::allocator<std::basic\_string<char, std::char\_traits<char>, std::allocator<char>>>>&) (/root/src/hypertable/src/cc/DfsBroker/Lib/Client.cc:615): File hdfs://namenode:8020/hypertable/servers/rs8/log/3/19/mhXJ7oobjVGJEjtY-1356744895 does not exist.

**解决方法：**

手动创建一个空的目录（sudo –u hdfs hadoop fs –mkdir  /hypertable/servers/rs8/log/3/19/mhXJ7oobjVGJEjtY-1356744895），然后重新启动RangeServer服务。

**10. 如何删除临时表**

**版本：目前的所有版本**

**问题描述：**

当查询结果比较大时，会产生一些临时表，例如：tmp/08eb3540-8ba1-44a8-ae9c-9c778ef5814d。查询正常结束时，临时表会被清除，但是如果查询异常结束，这些临时表将会一直存在。

**解决方法：**

使用下列命令删除临时表：  
use tmp;

drop table "08eb3540-8ba1-44a8-ae9c-9c778ef5814d";   //即在表名上加引号

**11. 如何增加scanner\_get\_cell方法返回的Cell数目**

**版本：目前的所有版本**

**问题描述：**

当使用scanner\_get\_cell接收查询结果时，如果查询结果较大，需要接收多次。为了减少接收次数，可以设置增加该方法每次接收的Cell数目。

**解决方法：**

修改hypertable.cfg文件中的以下两个配置项，修改后需要重启Hypertable：  
Hypertable.RangeServer.Scanner.BufferSize=2000000 //默认值为1M

ThriftBroker.NextThreshold=256000 //默认值为128K

**12. RANGE SERVER row overflow**

**版本：目前的所有版本**

**问题描述：**

RangeServer日志中出现如下类似错误：

ERROR Hypertable.RangeServer : operator() (/root/src/hypertable/src/cc/Hypertable/RangeServer/MaintenanceQueue.h:162): Hypertable::Exception: Unable to determine split row for range 2/9\[9999999103-5088A416Bzz..D0---0---0---0---0-000\] - RANGE SERVER row overflow

**解决方法：**

本问题是由于row设计不合理，或者入库程序生成了非预期的row所致。Hypertable目前规定 一个row不能跨range存在，所以当出现前述两个问题的话，则可能出现一个row的cell太多，从而“挤爆”了一个range，从而出现此错误。有两种解决方法：

1）修改Hypertable.RangeServer.Range.RowSize.Unlimited为true，然后重启hypertable。此方法不推荐，应尽量使用第二种方法；

2）设计合理的row，并保证入库程序生成预期的row。

注意不能通过增大Hypertable.RangeServer.Range.SplitSize配置值来解决此问题，因为该配置项修改后不能改变之前已经生效的数据。

**13. ThriftBroker抛出异常“org.apache.thrift.transport.TTransportException: Frame size (144130118) larger than max length (16384000)!**

**版本：目前的所有版本**

**问题描述：**

当使用HQL或者Thriftclient查询时，如果结果集较大（例如百万计行），则会抛出这个异常

**解决方法：**

1）当使用hql\_exec API时，请设置参数unbuffered为true；

2）连接ThriftBroker时修改framesize和timeout，framesize默认值为20M，timeout默认值为1600000毫秒。例如以下为Java代码将framesize修改为20M：  
ThriftClienttc = ThriftClient.create("localhost", 38080, 1600000, true, 20 \* 1024 \* 1024);

3）在MapReduce时，可在配置文件中修改配置项：hypertable.mapreduce.thriftclient.framesize

**14. Hypertable::Exception: decoding scan spec - SERIALIZATION input buffer overrun**

**版本：目前的所有版本**

**问题描述：**

RangeServer日志中出现如下类似错误：

ERROR Hypertable.RangeServer : run (/root/src/hypertable/src/cc/Hypertable/RangeServer/RequestHandlerCreateScanner.cc:65): Hypertable::Exception: decoding scan spec - SERIALIZATION input buffer overrun

**解决方法：**

此错误一般是由于客户端和服务器端使用了不同的hypertable版本，假设：集群升级时，集群端已经升级为0.9.7.17，但是入库程序还使用的是0.9.7.12的库，此时可能会出现此问题。只要将客户端程序在新的版本下编译，或者客户端采用新的jar即可。

**15. 大部分RangeServer在执行GC compaction时内存暴涨，导致集群无法提供服务**

**版本：0.9.7.12**

**问题描述：**

如题目所述

**解决方法：**

社区承认之前的GC compaction算法有些混乱，在0.9.7.17中已经大改了这个逻辑。升级到该版本或者之后的版本即可解决此问题。

**16. java.io.IOException: All datanodes \*.\*.\*.\*:50010 are bad. Aborting**

**版本：目前的所有版本**

**问题描述：**

RangeServer日志中出现如下类似错误：

ERROR Hypertable.RangeServer : run\_compaction (/root/src/hypertable/src/cc/Hypertable/RangeServer/AccessGroup.cc:790): 2/0\[1065795555-52B2C735BKA..10658000---52ABC9F3BKA\](IDX) Hypertable::Exception: Problem writing to DFS file '/hypertable/tables/2/0/IDX/YStGMh3ejopuOguz/cs717' : java.io.IOException: All datanodes \*.\*.\*.\*:50010 are bad. Aborting... - DFS BROKER i/o error  
    at virtual void Hypertable::CellStoreV6::add(const Hypertable::Key&, Hypertable::ByteString) (/root/src/hypertable/src/cc/Hypertable/RangeServer/CellStoreV6.cc:478)

**解决方法：**

虽然看起来很明显是访问HDFS出错，但是这是一个比较复杂的问题，目前已知两种情况可能引发这个错误：

1）HDFS的DataNode出现卷故障，故导致卷访问失败。此时修复故障卷即可。

2）操作系统或者HDFS的一些特殊权限被修改。这种情况后果很严重，极端情况下，只要对hypertable执行写入就报这个错误。如果不能确定被修改的权限项，即使cleandb也不能解决此问题，只能从重装操作系统开始了。所以杜绝此问题的方法就是严格管理集群的权限。

**17. java.io.IOException: Failed on local exception: com.google.protobuf.InvalidProtocolBufferException: Message missing  
required fields: callId, status**

**版本：目前的所有版本**

**问题描述：**

Master日志中出现如下类似错误：

ERROR Hypertable.Master : main (/root/src/hypertable/src/cc/Hypertable/Master/main.cc:384): Hypertable::Exception:  
Error checking existence of DFS path: /hypertable/servers/master/log/mml - DFS BROKER i/o error  
        at virtual bool Hypertable::DfsBroker::Client::exists(const String&) (/root/src/hypertable/src/cc/DfsBroker/Lib/Client  
.cc:679)  
        at virtual bool Hypertable::DfsBroker::Client::exists(const String&) (/root/src/hypertable/src/cc/DfsBroker/Lib/Client  
.cc:673): java.io.IOException: Failed on local exception: com.google.protobuf.InvalidProtocolBufferException: Message missing  
required fields: callId, status

**解决方法：**

这是由于hypertable和cdh版本不兼容引起的，一般是由于使用了过高的cdh版本。解决此问题需要执行下列修改：

1）修改hypertable源码目录下src\\java\\Core\\org\\hypertable\\DfsBroker\\hadoop\\2\\HadoopBroker.java中

DFSClient.DFSDataInputStream in =   (DFSClient.DFSDataInputStream)mFilesystem.open(path)为

HdfsDataInputStream in =  (HdfsDataInputStream)mFilesystem.open(path)

然后将该文件编译后替换“hypertable-版本号.jar”中同名的class；

2）在hypertable安装目录的子目录lib/java中，将所有cdh的jar替换为cdh新版本的jar。然后重启hypertable即可。

**18. java.io.IOException: Failed to add a datanode**

**版本：目前的所有版本**

**问题描述：**

RangeServer日志中出现如下类似错误：

java.io.IOException: Failed to add a datanode.  User may turn off this feature by setting dfs.client.block.write.replace-datanode-on-failure.policy in

**解决方法：**

此问题一般出现在小的HDFS集群中（5个datanode以内）。需要在各个DataNode节点的hdfs-site.xml中添加下列配置片段即可：

<name>dfs.client.block.write.replace-datanode-on-failure.enable</name>

<value>false</value>

</property>

也可通过cloudera manager添加上述配置片段，需要操作的配置项为HDFS Client Advanced Configuration Safety Valve。对于cloudera manager4系列，配置入口为：Client->advanced，对于cloudera manager5系列，配置入口为：Gateway Default Group->advanced。修改后需要执行Actions->Deploy Client Configuration，实践发现在HDFS服务页面执行下发操作不生效，但在YARN服务页面执行则会生效。

**19. Master MetaLog本地备份文件和HDFS文件不一致**

**版本：目前的所有版本**

**问题描述：**

Master不能正常启动，并且日志中出现类似下列错误：

ERROR Hypertable.Master : main (/root/src/hypertable/src/cc/Hypertable/Master/main.cc:384): Hypertable::Exception: MetaLog file '/hypertable/servers/master/log/mml/2' has

length 7730400 backup file '/dinglicom/hypertable/0.9.7.17/run/log\_backup/mml/master\_38050/2' length is 7724704 - METALOG backup file mismatch

at void Hypertable::MetaLog::Reader::verify\_backup(int32\_t) (/root/src/hypertable/src/cc/Hypertable/Lib/MetaLogReader.cc:129)

**解决方法：**

此问题是由于存储在HDFS上的Master MetaLog与本地备份文件不同步所致，所以需要手动同步。同步方法就是用错误信息中提到的HDFS上的MetaLog文件替换本地备份的同名文件，然后重启集群即可，本例中就是用/hypertable/servers/master/log/mml/2 替换 /dinglicom/hypertable/0.9.7.17/run/log\_backup/mml/master\_38050/2。当然，为了保险起见，建议替换前先备份文件。