0

最近我们遇到了一个问题，如标题中所述，每月一次。在 Metastore 节点上，我们已经安装并启动了 ntpd 服务以与 kerberos 服务器同步时间。节点上的 krb5.conf 如下所示：

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

因此，metastore 上的时间与 kerberos 服务器（>=5 分钟）不同步导致问题或网络阻塞的可能性似乎较小。
从metastore日志看，“Clock skew too great”异常记录时间是乱序的，比如，

2016-01-16 18:18:48,071 错误 [pool-3-thread-63735]
2016-01-16 19:07:03,699 错误 [pool-3-thread-63798]
2016-01-16 19:06:55,998错误 [pool-3-thread-63796]
2016-01-16 19:06:41,653 错误 [pool-3-thread-63812]
2016-01-16 19:04:28,659 错误 [pool-3-thread-63806]
2016-01-16 19:04:13,937 错误 [pool-3-thread-63804]
2016-01-16 19:02:19,312 错误 [pool-3-thread-63809]
2016-01-16 19:02:13,115错误 [pool-3-thread-63794]
2016-01-16 19:02:06,028 错误 [pool-3-thread-63800]
2016-01-16 19:01:50,767 错误 [pool-3-thread-63795]
2016-01-16 18:59:36,926 错误 [pool-3-thread-63810]
2016-01-16 18:59:36,394 错误 [pool-3-thread-63797]

异常堆栈：

2016-01-16 18:59:36,394 错误 [pool-3-thread-63797]: transport.TSaslTransport (TSaslTransport.java:open(296)) - SASL 协商失败
javax.security.sasl.SaslException：GSS 启动失败 [由 GSSException 引起：在 GSS-API 级别未指定故障（机制级别：时钟偏差太大（37））]
        在 com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:177)
        在 org.apache.thrift.transport.TSaslTransport$SaslParticipant.evaluateChallengeOrResponse(TSaslTransport.java:509)
        在 org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:264)
        在 org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
        在 org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$HiveSaslServerTransportFactory.getTransport(HadoopThriftAuthBridge.java:172)
        在 org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge20S.java:678)
        在 org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge20S.java:675)
        在 java.security.AccessController.doPrivileged（本机方法）
        在 javax.security.auth.Subject.doAs(Subject.java:356)
        在 org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1536)
        在 org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge20S$Server$TUGIAssumingTransportFactory.getTransport(HadoopThriftAuthBridge20S.java:675)
        在 org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:189)
        在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        在 java.lang.Thread.run(Thread.java:744)
原因：GSSException：在 GSS-API 级别未指定故障（机制级别：时钟偏差太大 (37)）
        在 org.apache.thrift.transport.TSaslServerTransport.handleSaslStartMessage(TSaslServerTransport.java:125)
        在 org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:253)
        在 org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
        在 org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$HiveSaslServerTransportFactory.getTransport(HadoopThriftAuthBridge.java:172)  
        ... 10 更多

环境：

java版本“1.7.0_45”
 Java HotSpot(TM) 64 位服务器 VM（内部版本 24.51-b03，混合模式）
 hive-0.13.1.2.1.10.0-hdp

那么，如果我想找出根本原因，我该怎么办？有什么建议么？非常感谢。

4

3 回答 3

3

我也看到过这个错误，就我而言，根本原因与 Kerberos 无关。如果您使用 MySql 数据库作为数据存储，则会出现非常严重的内存泄漏，https://issues.apache.org/jira/browse/HIVE-15551，这是在 0.13 中引入的，直到 Hive 1.3 才修复。 0。基本上，最初编写代码的人要么忘记了，要么没有意识到您必须显式关闭 JDBC 语句，当您的进程达到其内存限制时，这会导致过多的垃圾收集。一旦发生这种情况，过程中的一切都会变得越来越慢，直到您开始看到这些时钟偏差错误。

您可以通过在元存储进程上运行 jmap 实时直方图来判断这是否是您的问题。如果您在列表顶部看到 JDBC 对象（在我的例子中是 com.mysql.jdbc.JDBC42ResultSet 和 com.mysql.jdbc.StatementImpl），您可能遇到了这个问题。我建议您应用补丁，升级到 Hive 1.3.0，或者使用问题中提到的解决方法来查看是否可以解决问题。

于 2017-05-03T19:36:08.910 回答
1

使用kdestroy命令，然后kinit.

该kdestroy命令会破坏用户的活动 Kerberos 授权票证并删除包含它们的凭证缓存。

kinit用于获取和缓存 Kerberos 票据授予票据

删除缓存并再次“启动”可能会解决您的问题。如果没有缓存，kdestroy将返回“kdestroy：销毁缓存时未找到凭据缓存”。

kdestroy文档可以在这里找到。

于 2019-08-15T18:57:57.773 回答
0

运行此命令以将您的时钟与 KDC 同步：

/sbin/服务 ntpd 停止；/usr/sbin/ntpdate IP_Address_of_KDC_server; /sbin/service ntpd 启动

于 2021-01-30T23:01:08.913 回答