You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Sankar Hariappan (JIRA)" <ji...@apache.org> on 2017/06/28 08:05:00 UTC

[jira] [Comment Edited] (HIVE-16785) Ensure replication actions are idempotent if any series of events are applied again.

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

Sankar Hariappan edited comment on HIVE-16785 at 6/28/17 8:04 AM:
------------------------------------------------------------------

[~anishek]
The test failures for TestReplicationScenariosAcrossInstances are due to close of singleton pmf (by HIVE-16844) which doesn't allow creating multiple instances of metastore. These failures are not due to my patch.
I put a hack and tested with my patch locally which worked fine.

Request [~thejas]/[~sushanth] to please review/commit the patch!


was (Author: sankarh):
[~anishek]
The test failures for TestReplicationScenariosAcrossInstances are due to close of singleton pmf (by HIVE-16844) which doesn't allow creating multiple instances of metastore. These failures are not due to my patch.
I put a hack and tested with my patch locally which worked fine.

> Ensure replication actions are idempotent if any series of events are applied again.
> ------------------------------------------------------------------------------------
>
>                 Key: HIVE-16785
>                 URL: https://issues.apache.org/jira/browse/HIVE-16785
>             Project: Hive
>          Issue Type: Sub-task
>          Components: Hive, repl
>    Affects Versions: 2.1.0
>            Reporter: Sankar Hariappan
>            Assignee: Sankar Hariappan
>              Labels: DR, replication
>             Fix For: 3.0.0
>
>         Attachments: HIVE-16785.01.patch, HIVE-16785.02.patch, HIVE-16785.03.patch, HIVE-16785.04.patch, HIVE-16785.05.patch
>
>
> Some of the events(ALTER, RENAME, TRUNCATE) are not idempotent and hence leads to failure of REPL LOAD if applied twice or applied on an object which is latest than current event. For example, if TRUNCATE is applied on a table which is already dropped will fail instead of noop.
> Also, need to consider the scenario where the object is missing while applying an event. For example, if RENAME_TABLE event is applied on target where the old table is missing should validate if table should be recreated or should treat the event as noop. This can be done by verifying the DB level last repl ID against the current event ID.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)