Closed SGITLOGIN closed 3 weeks ago
the invocation chain is
DBeaver => JDBC driver => Kyuubi Server => Spark Driver => HMS => HDFS
the error you reported indicates that HMS => HDFS
may have issues when NN fails over.
@pan3793 Hello, there is no such problem when using beeline to access hive. Hive will first access the first namenode internally. If the first namenode is standby, it will also report the error Operation category READ is not supported in state standby, and then access the second namenode. However, the current phenomenon when using kyuubi to query is that when accessing a cluster with Kerberos authentication through dbever, the first namenode will be accessed first. If it is found to be in standby state, this error will be thrown directly without looking for the second namenode. Is this design method caused by dbever or kyuubi?
HDFS Configurations
I tried using RequestHedgingProxyProvider for the dfs.client.failover.proxy.provider parameter to no avail.
Debug your HMS process to figure out what happened.
@pan3793 Hello, the hive server only reports this and no other logs. Is it possible that dbever is not adapted to this mechanism? dfs.client.failover.proxy.provider.ha-nn=org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
After turning on HDFS high availability, you need to manually change the location addresses of the sys and information_schema libraries in hive: hdfs://ali-odp-test-01.huan.tv:8020/warehouse/tablespace/managed/hive/sys.db hdfs://ali-odp-test-01.huan.tv:8020/warehouse/tablespace/managed/hive/information_schema.db change: hdfs://ha-nn/warehouse/tablespace/managed/hive/sys.db hdfs://ha-nn/warehouse/tablespace/managed/hive/information_schema.db
So this is caused by the obsolete path in HMS for existing databases/tables after enabling NameNode HA, SPARK-22121 was raised (by Cloudera) to tackle such issues by converting namenode to nameservice, but unfortunately, it was rejected by the Spark community. The patch might be included in Cloudera's Spark.
Ok, thanks
Code of Conduct
Search before asking
Describe the bug
problem
The kyuubi server is configured with both Kerberos and LDAP authentication. HDFS is highly available. When I use dbever to access kyuubi and query hive, I always access the namenode corresponding to the previous nn1. When nn1 is the master, there is no problem with dbever access. When nn1 is in standby mode, an error will be reported. How to deal with this problem?
namenode high availability configuration
When nn1 is standby, the following error is reported
When nn1 is the master, access is normal
Affects Version(s)
1.9.2
Kyuubi Server Log Output
Kyuubi Engine Log Output
No response
Kyuubi Server Configurations
Kyuubi Engine Configurations
No response
Additional context
No response
Are you willing to submit PR?