hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-17657) export/import for MM tables is broken
Date Thu, 19 Oct 2017 21:55:00 GMT

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

Sergey Shelukhin commented on HIVE-17657:
-----------------------------------------

This was broken even in tests after one of the master merges.
Also even before that, when it was "working" in tests, it looks like some commit since 2e602596f7af6c302fd23628d4337673ca38be86
has removed the call to getValidMmDirectoriesFromTableOrPart, and I'm not sure it added anything
in return. Need to take a look at that first, and then fix the runtime error (some file is
missing).

> export/import for MM tables is broken
> -------------------------------------
>
>                 Key: HIVE-17657
>                 URL: https://issues.apache.org/jira/browse/HIVE-17657
>             Project: Hive
>          Issue Type: Sub-task
>          Components: Transactions
>            Reporter: Eugene Koifman
>
> there is mm_exim.q but it's not clear from the tests what file structure it creates 
> On import the txnids in the directory names would have to be remapped if importing to
a different cluster.  Perhaps export can be smart and export highest base_x and accretive
deltas (minus aborted ones).  Then import can ...?  It would have to remap txn ids from the
archive to new txn ids.  This would then mean that import is made up of several transactions
rather than 1 atomic op.  (all locks must belong to a transaction)
> One possibility is to open a new txn for each dir in the archive (where start/end txn
of file name is the same) and commit all of them at once (need new TMgr API for that).  This
assumes using a shared lock (if any!) and thus allows other inserts (not related to import)
to occur.
> What if you have delta_6_9, such as a result of concatenate?  If we stipulate that this
must mean that there is no delta_6_6 or any other "obsolete" delta in the archive we can map
it to a new single txn delta_x_x.
> Add read_only mode for tables (useful in general, may be needed for upgrade etc) and
use that to make the above atomic.



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

Mime
View raw message