Cloudera Docs

Known Issues in Apache Hive

Learn about the known issues in Hive, the impact or changes to the functionality, and the workaround.

Known Issues identified in Cloudera Runtime 7.3.1.1000 SP3 CHF5

CDPD-98415: Hive ACID incremental replication fails with "MetaException: invalid write id"
During Hive ACID incremental replication, the replication load task fails with a metastore exception similar to the following:
Caused by: org.apache.hadoop.hive.metastore.api.MetaException: invalid write id <ID> for table <db_name>.<table_name>

This issue occurs when processing a large volume of incremental replication events (such as bulk DDLs, partition operations, or TRUNCATE TABLE queries).

When the load builder batches events across multiple task iterations (controlled by hive.repl.approx.max.load.tasks), proactive transaction cleanup logic (CLEAR_DANGLING_TXNS) executes prematurely at the end of a batch iteration instead of at the end of the full incremental load operation. If an open transaction is replayed in one batch, but its corresponding commit event is scheduled in the subsequent batch, the cleanup task prematurely aborts the in-flight target transaction and invalidates its write ID.

If an upgrade to Cloudera Runtime 7.1.9 SP2 is not immediately possible, disable the proactive dangling transaction cleanup logic and enforce strict database cleanup ordering:
  1. Disable dangling transaction cleanup:
    Set hive.repl.clear.dangling.txns.on.target to false globally in Cloudera Manager under Hive Service Advanced Configuration Snippet (Safety Valve) or explicitly in both REPL DUMP and REPL LOAD commands:
    1. Source Cluster (REPL DUMP):
      REPL DUMP <db_name> WITH (
  'hive.repl.replica.external.table.base.dir'='hdfs://<target-hdfs-host>:8020/',
  'hive.repl.rootdir'='hdfs://<target-hdfs-host>:8020/warehouse/tablespace/staging/<db_name>',
  'hive.repl.run.data.copy.tasks.on.target'='true',
  'hive.repl.clear.dangling.txns.on.target'='false'
);
    2. Target Cluster (REPL LOAD):
      REPL LOAD <db_name> INTO <db_name> WITH (
  'hive.repl.replica.external.table.base.dir'='hdfs://<target-hdfs-host>:8020/',
  'hive.repl.rootdir'='hdfs://<target-hdfs-host>:8020/warehouse/tablespace/staging/<db_name>',
  'hive.repl.run.data.copy.tasks.on.target'='true',
  'hive.repl.clear.dangling.txns.on.target'='false'
);
  2. Enforce database cleanup order during re-bootstrap:
    When hive.repl.clear.dangling.txns.on.target is set to false, administrators must follow a strict order during re-bootstrap operations to prevent orphan entries in the Hive Metastore:

    1. Delete the Replication Policy First: Always remove the replication schedule or policy before deleting the database.

    2. Drop the Target Database Second: Dropping the database before the policy removes database metadata while leaving stale entries in REPL_TXN_MAP.

    3. Verify Metastore State: Before initiating a re-bootstrap load, run the following SQL query directly on the Target Hive Metastore database to verify no lingering entries exist for the policy:
      SELECT * FROM REPL_TXN_MAP WHERE RTM_REPL_POLICY = '<db_name>.*';

Apache Jira: HIVE-29459

Known Issues identified in Cloudera Runtime 7.3.1.900 SP3 CHF 4

CDPD-107262: Database drop operations fail in hybrid environments
7.3.1.900
In a hybrid environment that contains a Cloudera Data Hub 7.3.1.x and a 7.1.9 SP2 data lake, running the DROP DATABASE CASCADE command fails with an exception message 'fails with Invalid method name: 'drop_database_req' '. This issue occurs because the newer client calls a Hive Metastore API that does not exist in version 7.1.9 SP2.
Drop the tables, and then run the DROP DATABASE command instead of the DROP DATABASE CASCADE command.

Known Issues identified in Cloudera Runtime 7.3.1.706 SP3 CHF 2

There are no new known issues identified in this release.

Known Issues identified in Cloudera Runtime 7.3.1.600 SP3 CHF1

DWX-22436: DL upgrade recovery fails due to Metastore schema incompatibility
7.3.1.600
When attempting a Data Lake (DL) upgrade recovery from version 7.2.18.1100 to Cloudera Runtime 7.3.1.500, the process fails because the Hive Metastore schema versions are incompatible. The error indicates a mismatch between the Hive version (3.1.3000.7.3.1.500-182) and the database schema version (3.1.3000.7.2.18.0-Update2). This blocks Data Lake recovery if an upgrade fails, impacting customers.
Before you initiate the recovery process, manually update the Hive Metastore schema to match the target version by using the schematool utility.
  1. Obtain the Hive database password: Run the following command to retrieve the password from the pillar configuration: 
    cat /srv/pillar/postgresql/postgre.sls
  2. Back up the existing configuration: Move the current configuration directory to a backup location: 
    mv /etc/hive/conf /etc/hive/conf_backup
mkdir /etc/hive/conf
  3. Prepare the temporary configuration: Copy the process files to the new configuration directory: 
    scp /var/run/cloudera-scm-agent/process/<process-id>-hive-metastore-create-tables/* /etc/hive/conf/
  4. Update the connection password: Open the /etc/hive/conf/hive-site.xml file and perform the following modifications:
    • Set the javax.jdo.option.ConnectionPassword property to your Hive database password.
    • Comment out the hadoop.security.credential.provider.path property.
  5. Run the schema upgrade tool: Execute the schematool to synchronize the version: 
    /opt/cloudera/parcels/CDH/lib/hive/bin/schematool -dbType postgres -initOrUpgradeSchema --verbose
  6. Restore the original configuration: Remove the temporary directory and restore your backup: 
    rm -rf /etc/hive/conf
mv /etc/hive/conf_backup /etc/hive/conf
  7. Restart the cluster: Restart the services to initialize the Hive Metastore with the updated schema.

Known Issues identified in Cloudera Runtime 7.3.1.500 SP3

CDPD-88865: Unicode character support with a MySQL backend
Cloudera on premises 7.3.1.500 and all base versions
When a cluster's backend is a MySQL database, CREATE TABLE statements with more than two Unicode column names can fail. This is a known bug, HIVE-18083, where the MySQL database does not support non-ASCII characters in column names.
None

Known Issues identified in Cloudera Runtime 7.3.1.400 SP2

There are no new known issues identified for Hive in this release.

Known Issues identified in Cloudera Runtime 7.3.1.300 SP1 CHF1

There are no new known issues identified for Hive in this release.

Known issues identified in Cloudera Runtime 7.3.1.200 SP 1

There are no new known issues identified for Hive in this release.

Known Issues identified in Cloudera Runtime 7.3.1.100 CHF1

The following section lists the known issues identified in this release:
CDPD-77738: Atlas hook authorization issue causing HiveCreateSysDb timeout
7.1.9 SP1 CHF4, 7.1.7 SP3 CHF7, 7.3.1.100, and its higher versions
Atlas hook authorization error causes HiveCreateSysDb command to time out due to repeated retries.
None
CDPD-78490: HiveCreateSysDb command fails
7.1.9 SP1, 7.3.1.0, and its higher versions
Hive services fail to start due to HiveCreateSysDb command failure during the first run.
None
CDPD-72605: Optimizing partition authorization in HiveMetaStore
7.3.1.200
7.3.1.0
The add_partitions() API in HiveMetaStore unnecessarily authorizes both new and existing partitions, increasing processing time and load on the authorization service.
None

Known Issues identified in Cloudera Runtime 7.3.1

CDPD-74680: DAG not retried after failure
7.3.1 and its higher versions
When executing a Hive query, if the ApplicationMaster container fails, Hive does not retry the DAG if the failure message contains some diagnostic information including a line break, leading to query failure (instead of retry).
None
HiveServer2 goes into a hung state intermittently
7.3.1 and its higher versions
HiveServer2 can intermittently hang or crash due to heap out-of-memory (OOM) errors triggered by the default 1 GB cache limit for fetch tasks. This occurs with certain queries that exceed the available heap space.
  1. Disable the fetch task caching feature by setting: hive.fetch.task.caching=false.
  2. You can adjust the hive.fetch.task.conversion.threshold property to a lower value in the megabyte range. The default value in Cloudera on premises 7.3.1 is 1 GB.