ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (AMBARI-13987) Set hive.metastore.schema.verification=true in hive-site.xml
Date Fri, 20 Nov 2015 14:20:11 GMT


Hudson commented on AMBARI-13987:

FAILURE: Integrated in Ambari-trunk-Commit #3875 (See [])
AMBARI-13987. Set hive.metastore.schema.verification=true in (dlysnichenko: [])
* ambari-server/src/main/resources/stacks/HDP/2.2/services/HIVE/configuration/hive-site.xml

> Set hive.metastore.schema.verification=true in hive-site.xml
> ------------------------------------------------------------
>                 Key: AMBARI-13987
>                 URL:
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.1.3
>            Reporter: Dmitry Lysnichenko
>            Assignee: Dmitry Lysnichenko
>             Fix For: 2.1.3
>         Attachments: AMBARI-13987.patch
> We would like to have the following settings in hive-site.xml for installs of 2.1 onwards
> hive.metastore.schema.verification=true
> In addition, I think we may already have the following as the case, but just in case
they aren't, I'd like to list the following two as well:
> datanucleus.autoCreateSchema=false
> datanucleus.fixedDatastore=true
> *Background*:
> The Hive metastore has an issue wherein it tries to be non-strict about the schema version
of the metastore db, and it can try to update the schema version if it finds that it is itself
a newer version.
> This pairs well with things like autoCreateSchema, but since we're using SchemaTool to
set up our schema, and at no point should we be allowing the metastore to update the schema
itself, we would like to make sure that the schema validation step is a "strict" one, leading
to metastore failure if the version number does not match, instead of the metastore simply
updating the version.
> In addition, there seems to be a bug when the database access is slow or unreliable where
the metastore winds up creating multiple rows of entries in the schema table in some cases.
(This seems to happen rarely, but with more occurrences on AzureDB than others)

This message was sent by Atlassian JIRA

View raw message