[
https://issues.apache.org/jira/browse/HIVE-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16457362#comment-16457362
]
Sankar Hariappan commented on HIVE-17657:
-----------------------------------------
[~sershe], [~ekoifman],
I've couple of questions.
# How getAcidState lists these directories? If it returns mm_table_import,
then replication will also create the same structure at target with subdirs.
But, if it returns only delta_x_x_y list, then in target, we skip the parent
directory mm_table_import. Instead delta dir will be directly created in
warehouse data location. But of course includes the subdirs under delta dir.
# Will any of this directory contents change (such as add another delta
directory or rename etc) after listing new files for notification events? There
are no issues with compaction as it will archive these files to cmroot before
clean-up.
> 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
> Assignee: Sergey Shelukhin
> Priority: Major
> Labels: mm-gap-2
> Attachments: HIVE-17657.01.patch, HIVE-17657.02.patch,
> HIVE-17657.03.patch, HIVE-17657.04.patch, HIVE-17657.05.patch,
> HIVE-17657.patch
>
>
> 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
(v7.6.3#76005)
