The above exception happens when the hive schema is not available in the metastore instance. Please check in your init scripts to make sure the following flag is enabled to create hive Schema and tables if not already present.
datanucleus.autoCreateAll true
If the above option does not work, you can copy the Hive schema that you need (0.13, 2.1, 2.3 etc) and manually import the schema onto RDS using the follwing syntax -
mysql -h<host> -u<uname> -p <dbname> < hive_13.sql
Changes to metastore health are recorded in cluster events.
Look for "Metastore health check ok" or "Metastore health check failed" in the driver logs to see the status of this health check. Additionally you can check the cluster event logs for METASTORE_DOWN events to find any failed or timed-out health checks.
In addition to the above issue reported, this health check could fail under the following circumstances
- The metastore RDS is unreachable because of network connectivity from cluster IPs to metastore instance
- There is a high degree of concurrency and contention for metastore access.
Note that if the health check fails due to reason 2, it does not mean that the metastore is permanently down, just that it is temporarily unavailable. If a cluster consistently displays behavior where a METASTORE_DOWN event is registered but the MetastoreMonitor itself is up, it is due to reason 2 and can probably be fixed by increasing spark.databricks.hive.metastore.client.pool.size on the cluster and in few scenarios you might have to upgrade the metastore instance to allow higher concurrency.