hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hive QA (JIRA)" <>
Subject [jira] [Commented] (HIVE-20998) HiveStrictManagedMigration utility should update DB/Table location as last migration steps
Date Tue, 11 Dec 2018 07:00:01 GMT


Hive QA commented on HIVE-20998:

Here are the results of testing the latest attachment:

{color:red}ERROR:{color} -1 due to no test(s) being added or modified.

{color:green}SUCCESS:{color} +1 due to 15660 tests passed

Test results:
Console output:
Test logs:

Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase

This message is automatically generated.

ATTACHMENT ID: 12951316 - PreCommit-HIVE-Build

> HiveStrictManagedMigration utility should update DB/Table location as last migration
> ------------------------------------------------------------------------------------------
>                 Key: HIVE-20998
>                 URL:
>             Project: Hive
>          Issue Type: Sub-task
>            Reporter: Jason Dere
>            Assignee: Jason Dere
>            Priority: Major
>         Attachments: HIVE-20998.1.patch
> When processing a database or table, the HiveStrictManagedMigration utility currently
changes the database/table locations as the first step in processing that database/table.
Unfortunately if an error occurs while processing this database or table, then there may still
be migration work that needs to continue for that db/table by running the migration again.
However the migration tool only processes dbs/tables that have the old warehouse location,
then the tool will skip over the db/table when the migration is run again.
>  One fix here is to set the new location as the last step after all of the migration
work is done:
>  - The new table location will not be set until all of its partitions have been successfully
>  - The new database location will not be set until all of its tables have been successfully
> For existing migrations that failed with an error, the following workaround can be done
so that the db/tables can be re-processed by the migration tool:
>  1) Use the migration tool logs to find which databases/tables failed during processing.
>  2) For each db/table, change location of of the database and table back to old location:
>  ALTER DATABASE tpcds_bin_partitioned_orc_10 SET LOCATION 'hdfs://ns1/apps/hive/warehouse/tpcds_bin_partitioned_orc_10.db';
>  ALTER TABLE tpcds_bin_partitioned_orc_10.store_sales SET LOCATION 'hdfs://ns1/apps/hive/warehouse/tpcds_bin_partitioned_orc_10.db/store_sales';
>  2) Rerun the migration tool

This message was sent by Atlassian JIRA

View raw message