CDH HIVE报错引发的一系列血案

mac2026-08-12 6

今天偶尔发现一个CDH集群中的Hive MetaStore Server发生了异常，于是检查相关日志，具体日志为Hive MetaStore Server所在节点的/var/log/hive/hadoop-cmf-hive-HIVEMETASTORE-sbh01.esgyn.cn.log.out，日志报错如下，

2019-10-31 06:22:51,467 INFO org.apache.hadoop.hive.metastore.HiveMetaStore: [pool-5-thread-199]: 199: source:172.31.232.22 get_table : db=cloudera_manager_metastore_canary_test_db_hive_HIVEME TASTORE_89c6545c32a1b6da390011bba5c4799a tbl=CM_TEST_TABLE 2019-10-31 06:22:51,467 INFO org.apache.hadoop.hive.metastore.HiveMetaStore.audit: [pool-5-thread-199]: ugi=hue ip=172.31.232.22 cmd=source:172.31.232.22 get_table : db=cloudera_ manager_metastore_canary_test_db_hive_HIVEMETASTORE_89c6545c32a1b6da390011bba5c4799a tbl=CM_TEST_TABLE 2019-10-31 06:22:51,470 ERROR org.apache.hadoop.hive.metastore.RetryingHMSHandler: [pool-5-thread-199]: Retrying HMSHandler after 2000 ms (attempt 4 of 10) with error: javax.jdo.JDOException: E xception thrown when executing query at org.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:596) at org.datanucleus.api.jdo.JDOQuery.execute(JDOQuery.java:275) at org.apache.hadoop.hive.metastore.ObjectStore.getMTable(ObjectStore.java:1217) at org.apache.hadoop.hive.metastore.ObjectStore.getTable(ObjectStore.java:1024) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.hadoop.hive.metastore.RawStoreProxy.invoke(RawStoreProxy.java:103) at com.sun.proxy.$Proxy6.getTable(Unknown Source) at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.get_table_core(HiveMetaStore.java:1950) at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.get_table(HiveMetaStore.java:1905) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.hadoop.hive.metastore.RetryingHMSHandler.invokeInternal(RetryingHMSHandler.java:140) at org.apache.hadoop.hive.metastore.RetryingHMSHandler.invoke(RetryingHMSHandler.java:99) at com.sun.proxy.$Proxy8.get_table(Unknown Source) at org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$Processor$get_table.getResult(ThriftHiveMetastore.java:10128) at org.apache.hadoop.hive.metastore.api.ThriftHiveMetastore$Processor$get_table.getResult(ThriftHiveMetastore.java:10112) at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) at org.apache.hadoop.hive.metastore.TUGIBasedProcessor$1.run(TUGIBasedProcessor.java:110) at org.apache.hadoop.hive.metastore.TUGIBasedProcessor$1.run(TUGIBasedProcessor.java:106) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1924) at org.apache.hadoop.hive.metastore.TUGIBasedProcessor.process(TUGIBasedProcessor.java:118) at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:286) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) NestedThrowablesStackTrace: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'A0.OWNER_TYPE' in 'field list' at sun.reflect.GeneratedConstructorAccessor20.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:404) at com.mysql.jdbc.Util.getInstance(Util.java:387) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:939) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3878) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3814)

根据错误信息，我们怀疑是Hive的元数据库表出现了问题，根据错误信息，大概是表CM_TEST_TABLE的OWNER_TYPE字段没找到。于是我们去Hive的元数据库MYSQL中查询此表并希望检查此字段，不过并没有找到（可能是表存在但没找着位置）。由于此环境是一个测试环境，我们决定先采用删除Hive并重装的方式来绕过。于是从CM管理界面把Hive整个组件删除并重新添加，添加后发现启动Hive过一小会儿后仍然报同样的错。这是因为MYSQL元数据库中的Hive数据库仍然是有问题，删除Hive组件并没有删除MYSQL中的Hive数据库。因此，我们决定先删除MySQL中的Hive数据库并对Hive数据库进行初始化。那么问题来了，在删除Hive数据库时不小心删错了库，把MYSQL库删除了。。。执行的命令为：

/usr/share/mysql-5.6.31/bin/mysql -u root --password='xxx' show databases; drop database mysql;

删除了mysql库之后，我们发现再创建hive user时报错无法创建，这是因为mysql的database下面有张user表，所有的用户信息都存放于mysql.user里面。

现在mysql的database整个没有了，需要想办法恢复mysql这个database。我们从另外一套测试集群中进行mysql元数据库，查看发现mysql的数据库下面有28张表，部分表中有数据，表列表如下，

于是我们使用mysqldump命令把这些表结构和数据导出成一个文件，命令如下，

/usr/local/mysql/bin/mysqldump -uroot --password='xxx' --databases mysql >mysql.sql

将此文件拷贝到问题集群上，在mysql中执行此文件创建相应的表结构并导入数据，执行之后使用update语句更新其中的几条数据，因为有几条数据保存的IP和机器名是原环境的信息。

/usr/share/mysql-5.6.31/bin/mysql -u root --password='xxx' < mysql.sql --需要更新以下几个数据 use mysql; update user set host='172.31.232.22' where host='172.31.234.1'; update user set host='sbh02.esgyn.cn' where host='uathx02.esgyn.cn'; update user set host='sbh01.esgyn.cn' where host='uathx01.esgyn.cn'; update proxies_priv set host='sbh01.esgyn.cn' where host='uathx01.esgyn.cn';

现在，mysql的数据库算是已经恢复了，由于导出的mysql环境和目标环境里面的用户信息和密码基本都是一致的，我们也不需要特意去修改mysql.user表里面的信息，而且也不用再创建hive用户了，因为mysql.user表中已经有相应的记录了，我们需要做的就是删除MYSQL元数据库中的hive这个数据库并重新创建一个空的库，

/usr/share/mysql-5.6.31/bin/mysql -uroot --password='xxx' drop database hive; create database hive;

现在，我们再次从CM管理界面重新添加Hive组件并启动，此时Hive终于恢复了正常！

最新回复(0)