[
https://issues.apache.org/jira/browse/IMPALA-13989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17948045#comment-17948045
]
ASF subversion and git services commented on IMPALA-13989:
----------------------------------------------------------
Commit 295f74ef12df0b851058efe2c43c9826b617d21f in impala's branch
refs/heads/master from Michael Smith
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=295f74ef1 ]
IMPALA-13989: Invalidate table on rename failure
Handles the error "Table/view rename succeeded in the Hive Metastore,
but failed in Impala's Catalog Server" rather than failing the table
rename. This error happens when catalog state catches up to the alter
event from our alter_table RPC to HMS before we renameTable explicitly
in the catalog. The catalog can update independently due to a concurrent
'invalidate metadata' call.
In that case we use the oldTbl definition we already have - updated from
the delete log if possible - and fetch the new table definition with
invalidateTable to continue, automating most of the work that the error
message suggested users do via 'invalidate metadata <tbl>'.
Updated the test_concurrent_ddls test to remove handle_rename_failure
and ran the tests a dozen times. Adds concurrency tests with
simultaneous rename and invalidate metadata that previously would fail.
Change-Id: Ic2a276b6e5ceb35b7f3ce788cc47052387ae8980
Reviewed-on: http://gerrit.cloudera.org:8080/22807
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> ALTER TABLE RENAME can fail with concurrent INVALIDATE METADATA
> ---------------------------------------------------------------
>
> Key: IMPALA-13989
> URL: https://issues.apache.org/jira/browse/IMPALA-13989
> Project: IMPALA
> Issue Type: Bug
> Components: Catalog
> Affects Versions: Impala 5.0.0
> Reporter: Michael Smith
> Assignee: Michael Smith
> Priority: Minor
>
> IMPALA-13631 removes holding the catalog's versionLock_ writeLock during the
> whole operation (including HMS RPC). That introduces a possible failure mode
> where {{ALTER TABLE RENAME}} fails with
> {quote}Table/view rename succeeded in the Hive Metastore, but failed in
> Impala's Catalog Server.{quote}
> when {{INVALIDATE METADATA}} is run concurrently. This shows up in the new
> statements added to test_concurrent_ddls.py.
> I can reproduce this error by adding a delay after HMS {{alter_table}} RPC
> completes (and before we {{getNextMetastoreEventsForTableIfEnabled}}) and
> running {{INVALIDATE METADATA}} from another session. I think that suggests
> the scenario as:
> # {{alter_table}} RPC completes
> # Impala {{invalidate metadata}} executes and processes {{alter_table}} event
> # {{alterTableOrViewRename}} runs {{catalog_.alterTable}}, but old table has
> already been removed from the catalog so it fails
> This should be pretty rare. Running a global {{invalidate metadata}} is a bad
> idea in a production environment as it's akin to restarting catalogd. However
> I think we can address this with better error handling in
> {{alterTableOrViewRename}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
