在公司的虚拟机上运行hive计算，因为要计算的数据量较大，频繁，导致了服务器负载过高，mysql也出现无法连接的问题，最后虚拟机出现The remote system refused the connection.重启虚拟机后，进入hive。

hive> show tables;

出现了下面的问题：

FAILED: Error in metadata: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClient
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask
FAILED: Error in metadata: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClientFAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask

网上查找解决的办法：

看到有一些别人说明的原因，如：mysql的权限不够。修改数据库用户权限，或者hive/bin目录权限。还有告诉要在hadoop bin/hadoop namenode -format目录的（这个办法很扯，自己去查看一下hadoop fs -ls /，hadoop运行正常）。还有说要情况/tmp目录的。这些办法都不是真正解决问题的办法。

用下面的命令，重新启动hive

./hive -hiveconf hive.root.logger=DEBUG,console

hive> show tables;

能够看到更深层次的原因的是： 

    1.  Caused by: java.lang.reflect.InvocationTargetException
2.  
3.  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
4.  
5.  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
6.  
7.  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
8.  
9.  at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
10.  
11.  at org.apache.hadoop.hive.metastore.MetaStoreUtils.newInstance(MetaStoreUtils.java:1076)
12.  
13.  … 23 more
14.  
15.  Caused by: javax.jdo.JDODataStoreException: Exception thrown obtaining schema column information from datastore
16.  
17.  NestedThrowables:
18.  
19.  com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table ‘hive.DELETEME1370713761025′ doesn’t exist


    根据提示的信息，登陆mysql或者mysql客户端查看hive的数据库的表信息 

    mysql -u root -p 
mysql> use hive; 
mysql> show tables; 
+—————————+ 
| Tables_in_hive            | 
+—————————+ 
| BUCKETING_COLS            | 
| CDS                       | 
| COLUMNS_V2                | 
| DATABASE_PARAMS           | 
| DBS                       | 
| DELETEME1370677637267     | 
| DELETEME1370712928271     | 
| DELETEME1370713342355     | 
| DELETEME1370713589772     | 
| DELETEME1370713761025     | 
| DELETEME1370713792915     | 
| IDXS                      | 
| INDEX_PARAMS              | 
| PARTITIONS                | 
| PARTITION_KEYS            | 
| PARTITION_KEY_VALS        | 
| PARTITION_PARAMS          | 
| PART_COL_PRIVS            | 
| PART_COL_STATS            | 
| PART_PRIVS                | 
| SDS                       | 
| SD_PARAMS                 | 
| SEQUENCE_TABLE            | 
| SERDES                    | 
| SERDE_PARAMS              | 
| SKEWED_COL_NAMES          | 
| SKEWED_COL_VALUE_LOC_MAP  | 
| SKEWED_STRING_LIST        | 
| SKEWED_STRING_LIST_VALUES | 
| SKEWED_VALUES             | 
| SORT_COLS                 | 
| TABLE_PARAMS              | 
| TAB_COL_STATS             | 
| TBLS                      | 
| TBL_COL_PRIVS             | 
| TBL_PRIVS                 | 
+—————————+ 
36 rows in set (0.00 sec)

    能够看到“DELETEME1370713792915”这个表，问题明确了，由于计算的压力过大，服务器停止响应，mysql也停止了响应，mysql进程被异常终止，在运行中的mysql表数据异常，hive的元数据表异常。

    解决问题的办法有两个：

    1. 直接在mysql中drop 异常提示中的table; 

    mysql>drop table DELETEME1370713761025;

    2. 保守的做法，根据DELETEME*表的结构，创建不存在的表 

    CREATE TABLE `DELETEME1370713792915` (  `UNUSED` int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1;


    通过实践，第一个方法就能够解决问题，如果不行可以尝试第二个方法。



    总结：

    hive、hadoop的上层异常原因可能很多情况导致，一定要找到真正的问题原因，不能急于尝试网上异常的解决办法。hive的元数据依赖关系型数据库，一定做好数据库的备份

    又碰到一个hive的Exception，Caused by: org.apache.hadoop.hive.ql.parse.SemanticException: Unable to fetch table XXX，追溯更直接的原因，找到Caused by: java.sql.SQLException: Got error 28 from storage engine。

    问题原因：

    服务器的根目录的/tmp中日志文件生成过多，磁盘空间满了。以SemanticException: Unable to fetch table关键字在google中搜索，发现结果很少，也没什么有价值的信息，搜索结果是这种情况，说明这个问题不常见，很可能是其他低级错误导致的问题。