[
https://issues.apache.org/jira/browse/IMPALA-13989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18014076#comment-18014076
]
ASF subversion and git services commented on IMPALA-13989:
----------------------------------------------------------
Commit a68f7164589b5d554d7f9a948badbc414e6b944e in impala's branch
refs/heads/master from stiga-huang
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=a68f71645 ]
IMPALA-14307: Correctly update createEventId and DeleteEventLog in
AlterTableRename
When EventProcessor is paused, e.g. due to a global INVALIDATE METADATA
operation, in alterTableOrViewRename() we don't fetch the event id of
the ALTER_TABLE event. This causes the createEventId of the new table
being -1 and the DeleteEventLog entry of the old table is missing. So
stale ALTER_TABLE RENAME events could incorrectly remove the new table
or add the old table.
The other case is in the fallback invalidation added in IMPALA-13989
that handles rename failure inside catalog (but succeeds in HMS). The
createEventId is also set as -1.
This patch fixes these by always setting a correct/meaningful
createEventId. When fetching the ALTER_TABLE event fails, we try to use
the event id before the HMS operation. It could be a little bit stale
but much better than -1.
Modified CatalogServiceCatalog#isEventProcessingActive() to just check
if event processing is enabled and renamed it to
isEventProcessingEnabled(). Note that this method is only used in DDLs
that check their self events. We should allow these checks even when
EventProcessor is not in the ACTIVE state. So when EventProcessor is
recovered, fields like createEventId in tables are still correct.
Removed the code of tracking in-flight events at the end of rename since
the new table is in unloaded state and only the createEventId is useful.
The catalog version used is also incorrect since it's not used in
CatalogServiceCatalog#renameTable() so it doesn't make sence to use it.
Removed the InProgressTableModification parameter of
alterTableOrViewRename() since it's not used anymore.
This patch also fixes a bug in getRenamedTableFromEvents() that it
always returns the first event id in the list. It should use the rename
event it finds.
Tests
- Added e2e test and ran it 40 times.
Change-Id: Ie7c305e5aaafc8bbdb85830978182394619fad08
Reviewed-on: http://gerrit.cloudera.org:8080/23291
Reviewed-by: Riza Suminto <[email protected]>
Reviewed-by: Michael Smith <[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
> Fix For: Impala 5.0.0
>
>
> 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]
