[jira] [Comment Edited] (HIVE-20346) [Hive Upgrade] A rollback script is necessary when upgrade hive

["Sergey Shelukhin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HIVE-20346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591015#comment-16591015 ] 

Sergey Shelukhin edited comment on HIVE-20346 at 8/24/18 1:11 AM:
------------------------------------------------------------------

For a general case, this will be a lot of very painful work, given the fact that upgrade scripts can fail in the middle too, so the downgrades will need to account for all possible partial states. Additionally, some steps like dropping columns might not be reversible.
But, even for the basic case of reversing a successful upgrade and doing something sensible for non reversible ops, it would require someone to pair every upgrade script we have with a downgrade script... and Hive has a ton of upgrade scripts, esp. if you want to go all the way to 1.1.0.
Plus there'd need to be some code in the tool to run them, but that's similar to upgrade.

I think a good design might have been to use a state based design instead of operation based for most upgrade changes (where Hive would diff the schema and apply changes based on the diff, e.g. change column types, create tables, etc.). That would make downgrade trivial (again, for most schema changes, there are a couple complex upgrade scripts IIRC), and actually won't require separate upgrade scripts also, for most cases, wouldn't that be nice. However while less tedious and brittle than the first option, it would be a large feature to implement and test.



was (Author: sershe):
For a general case, this will be a lot of very painful work, given the fact that upgrade scripts can fail in the middle too, so the downgrades will need to account for all possible partial states. Additionally, some steps like dropping columns might not be reversible.
But, even for the basic case of reversing a successful upgrade and doing something sensible for non reversible ops, it would require someone to pair every upgrade script we have with a downgrade script... and Hive has a ton of upgrade scripts, esp. if you want to go all the way to 1.1.0.
Plus there'd need to be some code in the tool to run them, but that's similar to upgrade.

I think a good design might have been to use a state based design instead of operation based for most upgrade changes (where Hive would diff the schema and apply changes based on the diff, e.g. change column types, create tables, etc.). That would make downgrade trivial (again, for most schema changes, there are a couple complex upgrade scripts IIRC), and actually won't require separate upgrade scripts also, for most cases, wouldn't that be nice. However while less tedious and brittle than the other one, it would be a large feature to implement and test.


> [Hive Upgrade] A rollback script is necessary when upgrade hive
> ---------------------------------------------------------------
>
>                 Key: HIVE-20346
>                 URL: https://issues.apache.org/jira/browse/HIVE-20346
>             Project: Hive
>          Issue Type: Task
>            Reporter: wuchang
>            Assignee: wuchang
>            Priority: Major
>
> When we upgrade hive from a low version(1.1.0) to higher version(2.3.3),  we will have to:
>  # backup the old hive metastore database
>  # Use schema tool to upgrade the hive metastore database schema.
> Then several days after the upgrading, new version hive have some critical problems and we want to revert to previous hive, what could we do? Since during these days the data in hive metastore has changed. So, if we directly switch to the old hive metastore, any metadata changes after the upgrading will lose.
> So , I think we need a rollback script, which is used to downgrade our high version metastore schema to low version schema.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)