Bug #87812 Concurrent DDL operation in progress even after acquiring backup lock

• Submitted: 20 Sep 2017 5:18
• Modified: 5 Mar 2018 14:25
• Reporter: Debarun Banerjee
• Status: Closed
• Category: MySQL Server: Data Dictionary
• Severity: S3 (Non-critical)
• Version: 8.0.3
• OS: Any
• CPU Architecture: Any

[20 Sep 2017 5:18] Debarun Banerjee

Description:
While using service interface from "WL#9451:Backup Lock" from clone plugin, I observe that it could acquire "backup lock" successfully while concurrent DDL is still running.

This issue would impact both Clone and MEB.

How to repeat:
1. Stop DDL command "Drop Table" in fil_delete_tablespace() - Either in debugger or debug_sync

2. From another session do "LOCK INSTANCE FOR BACKUP"

Currently "Lock Instance" command finishes successfully, without waiting for the DDL to finish. 

Suggested fix:
Release Backup Lock only after DDL is complete.

We are releasing the backup lock in DDL too early ...

mysql_execute_command()

if (check_if_backup_lock_has_to_be_acquired(lex) &&
      acquire_shared_backup_lock(thd, thd->variables.lock_wait_timeout))
    DBUG_RETURN(1);

if (stmt_causes_implicit_commit(thd, CF_IMPLICIT_COMMIT_BEGIN))
  {
....
    /* Release metadata locks acquired in this transaction. */
    thd->mdl_context.release_transactional_locks();
  }

Since most DDL would implicitly commit the previous transaction (CF_IMPLICIT_COMMIT_BEGIN), the backup lock is getting released even before the DDL has started execution

bool acquire_shared_backup_lock(THD *thd, ulong lock_wait_timeout)
{
  return acquire_mdl_for_backup(thd, MDL_INTENTION_EXCLUSIVE, MDL_TRANSACTION,
                                lock_wait_timeout);
}
The shared backup lock is taken for transaction duration

[5 Mar 2018 14:25] Daniel Price

Posted by developer:
 
Fixed as of the upcoming 8.0.5 release, and here's the changelog entry:

A LOCK INSTANCE FOR BACKUP operation was able to acquire a backup lock
without wait for a concurrent DDL operation to finish.